

You’ll need MySQL binlogging enabled.įirst, take a full MySQL dump of your database… Now the important part, migrating your entire production database without going down for hours (hopefully less than a minute). Very useful if you need to deal with high read load on MySQL. If you want a server to handle only read queries, making it basically a slave, you can easily set one up by right clicking on the instance. You’ll need to add whatever IP’s/Security Groups you want to be able to access the server to DB Security Groups, or you won’t be able to connect.īy clicking on the arrow for the instance and looking for the Endpoint, you’ll find what host you should be connecting to. Select a backup window and maintenance window where your servers are at lowest load as the backup can use a fair amount of CPU and the maintenance window can have a restart within it (another reason to use Multi-AZ Deployment – you shouldn’t have any interruption).Īfter you’ve booted your server it should show as a DB Instance. In management options, enable automatic backups (losing data if things go monumentally wrong is not cool) and keep them for as long as you’d like. I’d recommend enabling Multi-AZ Deployment to help with uptime and redundancy, but it does cost more so it’s all about your needs. This is pretty easy, select whatever basic preferences you’d like, a DB Instance Identifier ( mysql-1 is probably descriptive enough) and a master username and password (which annoyingly can only be a max of 16 chars). It was therefore a good time to change MySQL to a different server, and RDS is a great option.

We also didn’t like having to maintain multiple MySQL servers and handle replication between them. The Multi-AZ deployment also means there should be minimal downtime should anything go wrong. They’re easy to maintain and scale whilst being pretty good value. At GoSquared, we recently migrated our MySQL databases over to Amazon RDS, here’s how and why we’ve done it.
