I am migrating to Amazon Web Services. I have a production site and associated mySQL Database, and I also have a staging site to try out changes prior to pushing to production.
In terms of AWS RDS, how do I manage these two databases? Should they both exist in the same instance, or should they each have their own instance?
My staging site does not have to be continuously available, does this change which option is best suited?
I think those databases should live in different instances. Production DB should definitely have its own instance. There are many reasons to that:
What happens if you have a bug in staging and you spam your instance with CPU-eating queries? If it is the same instance your production DB might be effected.
It is good to have instance monitoring only for production.
You will be able to set up configuration on the production instance that should not be set on staging such as multi-az availability.
You can stop the staging instance when ever you want and re-start it with just the data it had when you stopped it.
All in all, no reason to mix the two into the same instance. One for production, one for staging.
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 am new to Amazon RDS, and looking to get answer for my question below and couldn't find the answer on stackoverflow yet.
I have a MySQL Database on premise that I want to synchronize with the MySQL Database on Amazon RDS. I understand that replication is possible with Amazon RDS, but how about continuous synchronization? Say my existing local database has one transaction that has been made, I want to synchronize just that transaction, either immediately or by schedule, so that I don't need to replicate the whole thing to RDS.
Does RDS have this feature for MySQL or any other database?
If not, what tools should I be using? EC2 + ? ?
Or is there any database that supports this so I can just run the database on EC2?
Your best (first) option should probably be the AWS Database Migration Service. This is a migration service for exactly your use-case.
If uptime is less of an issue, you could always do a mysql_dump, move that to an EC2 instance and load that into an RDS instance.
I want to ask if I have 2 identical ec2 instances each with MySQL. If i add a load balancer on the front of the ec2 instances, the databases of ec2 will have the same data or every database will have the data that process by a request? In other words with elb the databases will be synchronized somehow or every database will have different information?
Many thanks!
I would recommend using Amazon's RDS. It is easier to setup and you do not need to manage the cluster. If you really want to manage the boxes yourself I would look at configuring Galera
Here is a tutorial from Digital Ocean, but it would work on AWS as well.
Hope I don't think two EC2 instances must have same data in MySQL DB. ELB will send request to any EC2 instances so data will update in one instance and not in another instance anyway MySQL DB are not synchronized between instances.
I recommend you to use Amazon RDS service which is relational database and it offers MySQL, MSSQL, PostgreSQL, Oracle and Amazon Aurora. You can use any database and enable high availability for good performance.
I have 2 amazon rds instance (one for production, and another for development/testing). Now I want to restore one database from production instance to my development instance. I am taking snapshots on my production instance, but there is no options to restore snapshots on development instance from another instance.
Is there any way to do this without downloading snapshot?
Restoring from snapshot means creating a new RDS instance, so you will basically be replacing the old development instance with a new one.
First you have to either delete or rename the original development instance, otherwise it's name can't be reused for the new instance.
If you want an RDS instance with both the development schema and production schema, then you'll have to transfer the data using database-specific tools (e.g., mysqldump if you're using MySQL, data pump if using Oracle, etc).
You can modify the attributes on the (production) snapshot and allow another AWS account (Dev, in your case) to access it
aws rds modify-db-snapshot-attribute --db-snapshot-identifier $SNAPSHOT_NAME --attribute-name restore --values-to-add "<ACCOUNT NUMBER FOR DEV>" --output=json
Attribute name = Restore, because you are having dev account restore from this snapshot.
in your dev console, you will find this on the "Shared snapshots"
Starting Late 2015, the sharing of snapshot has been added as a feature by AWS.
Sharing Snapshot across AWS Accounts
I'm running two MySQL server one on production and one on staging, both are EC2 Instance.
The same way i have two MySQL RDS Instances parallel to the production and staging.
Here want i wanted to do.
I would like to mirror the production database to the development server every few hours,
for 1. backup, 2. to run new features against the latest database changes.
I didn't find much information regarding this issue, can anyone help?
Thanks.
Additional information:
i'm running nginx on linux server, with php backend.
If you are running on RDS, you have two options.
Snapshot and restore your instance. You can automate this, but the time it make take more time the larger the DB is. Your endpoint will probably change too.
Dump the database from production, reload into development.