We have an ElasticBeanstalk instance, with an internal postgres database.
As you know, there's the possibility to have internal (coupled) or external (decoupled) databases on ElasticBeanstalk
Since last year, there is the possibility to decouple internal databases from an ElasticBeanstalk instance, since these are coupled or 'tied' to the instance itself.
We want to have an external database instead of the internal one, because the new external database is encrypted, anyway, that's the reason why we want to decouple the existing one.
But if I go EB->Environments->Environment->Configuration->Database section
Then click 'Decouple Database', it shows me a MySQL related error (???), the db is postgres, no doubts about it, there's no hint to MySQL at any point in the lifetime of this EB instance.
And if I try from the eb cli the error is different but always MySQL related:
Any ideas about this?
Related
I have defined a schema and populated with data into MySql on my laptop. However, due to the large-scale of the datasets, the computing time suffers in the following analysis stage in python. So I decide to try to move all my work to cloud. I'm wondering if there is anyway to let the server in AWS directly connect to the mysql server in my laptop so that I can use the existing datasets without recollect them.
You may be interested in AWS Database Migration Service.
You can use DMS database migration service of aws which will do everything for you.
https://aws.amazon.com/dms/
But you have to take care about foreign key and other data. sometime it is generating the error.
DMS will transfer all of your data from laptop to aws database which will be on RDS or you can choose.
I have installed ejabberd on an AWS EC2 instance and am using the smack library to connect to it with my android app. At the moment the ejabberd server is using mnesia as the database, however I want to perform some complex queries on some of the data (mainly the MUC room names), as SQL will predominantly the best solution for this, I was wondering if it was possible to replicate the required data to an external MySQL database that I could then query.
Is this possible or am i better looking at a different approach to this problem?
There is no module built into ejabberd to replicate data in Mnesia to MySQL. However, the usual approach is to use the backend you need for each feature. If you want mod_muc to store data into MySQL instead of Mnesia, you can just change the backend to odbc (which means it will store data for that module in a relational database).
You can refer to ejabberd documentation for MUC module: http://docs.ejabberd.im/admin/guide/configuration/#modmuc
Once your MySQL is configured and schema is loaded, you can set db_type to odbc on a case by case basis to choose MySQL for that module.
I'm trying to use an AWS data pipeline to pull data from an externally hosted MySQL datasource into an RDS MySQL instance.
Is this even possible? How can it be configured? I can't find anything about this in the documentation.
If it's not possible, is there any better option, or am I better to set up a manual push from the external server to the RDS instance?
Have you looked at SqlDataNode?
http://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-object-sqldatanode.html
This lets you provide a jdbc connection string to any MySql database.
Using CloudFormation, I'm trying to figure out a few use cases.
The first case is having an existing AWS RDS MySQL server, how to create a database, tables, and a user account though a CloudFormation template.
After looking at the Cloudformation docs, I thought there could be a
AWS::RDS::DBInstance property that would allow me to do this action; however, though I couldn't find how to specify a database host source (or I may have misread it) that would allow.
aws-properties-rds-database-instance
then, looking at the Cloudformation RDS templates from AWS, I saw an fn::join command that stood out. Would my first case be done with fn::join?
"UserData": { "Fn::Base64": { "Fn::Join": ["", [....
Next, in the second case, I'm also having trouble finding how using an existing RDS MySQL server, load a scheme from a MySQL mysqldump.
I've looked at the docs in the link above for answers but not quite sure. I noticed AWS templates mostly allow you to create resources.
Lastly, to solve the above two cases, I've also been reading that it could or should(?) be done using a two tool approach by way of using an AWS CloudFormation template and calls to Chef.
Thoughts?
Short answer is : you can't, right now, automatically run SQL queries at instance creation (in the future, who knows...).
I would use the following way to resolve this classic problem:
Use an EC2 to run the MySQL code you need (not sure if you need to put a "DependsOn" clause in the EC2, since you will have to refer to the RDS endpoint with a GetAtt, which will probably put an implicit DependsOn clause). You put this in the user data or any script you want, as long as you pass the RDS endpoint somehow. Of course, you will need the MySQL client package installed on your EC2.
As you wrote, CloudFormation allows you to create AWS resources, but populationg those resources is up to you. Once again, a MySQL client will do the trick (since a MySQL dump is no more than SQL code in a file, same as your initial requirement).
Using Chef or Puppet will not solve your problem alone, since both need an agent installed on an EC2, you cannot run your agent in the RDS server. So you can have an EC2 using a Chef or Puppet agent, which will in turn launch the MySQL script, but this will not give you much more than the previous solution
I have a java webapp using hibernate over MYSQL db. I need at least an hour of data maintenance daily, hence I need to bring down the db and switch to the backup db.
I don't see an elegant way to switch to another db from my app using hibernate. Is there?
Other totally different ways for database maintenance is welcome.
As you are using a Java WebApp, I assume you are using a container (like Tomcat) or an application server (like JBoss). In both cases, you should be using managed connections by the container, via JNDI. In such case, you can just use JMX (or the admin console) to change the actual datasource, to point to the backup DB, clean the pool and reopen new connections. When you are done, just perform the same steps, pointing the datasource to the actual database.
If you are not using managed connections by the container, you are out of luck. As the Hibernate configuration is static, you'll need to bring down your app, deploy a new version of it with your persistence.xml/hibernate.cfg.xml pointing to the backup, do the maintenance, and deploy the "old" version when you are done.