I’m replicating into Amazon from a physical datacenter

A: This setup is common if you’re using Amazon’s VPC or Virtual Private Cloud. With a router dropped into your datacenter, VPC allows you to extend and spinup virtual instances from Amazon as if they’re sitting in your own existing datacenter. Great stuff, but you won’t be able to replicate from your existing master MySQL instance to cloud Amazon RDS instances. To do that, roll your own with MySQL 5.5 or Percona 5.5. RDS can only work with other RDS instances. At least for right now.

I’m using Amazon and replicating to another cloud provider

A: Again roll your own, as RDS won’t work with this configuration.

I’m developer or small startup building a new application.

A: Use RDS. It’s easier to deploy, and though there are fewer levers and dials you can control, you can always dump your data and move it to roll your own deployment later.

We’re a small shop without a fulltime DBA

A: Use RDS as it is easier to deploy. You’ll have a couple of replication options at your disposal. There are read replicas which are basic slaves using MySQL’s built-in asyncronous replication. You can scale horizontally with these read-only copies, but cannot failover to these instances. For that you’ll need a multi-az configuration where you deploy across availability zones. Multi-az is said to be syncronous so it’s likely built on top of a distributed filesystem such as DRBD.

Keep in mind though there is no free lunch. RDS lacks the slow query log, which is the primary way you’ll identify errant queries, and fix them. You’ll need to be extra vigilant about QA & Test as code deploys add new SQL to your application. There *IS* a way to log slow queries to a table, which is ok for off and on use. However there’s quite some overhead to this feature being turned on all the time.

We want to do master-master for easy failover and failback

A: Use MySQL 5.5 or Percona 5.5. The two configurations for RDS don’t support this. With AWS Read Replicas you have one master and multiple read-only slaves, but no failover. With Multi-AZ you can’t access the inactive secondary database *until* you failover. Once you failover that instance becomes the primary.

I’m concerned about clean data. Is replication bulletproof?

A: No not out of the box. Whether you are using RDS or MySQL there are various scenarios where MySQL slaves can drift out of sync from the master, without throwing an error. This likely impacts Read Replicas though it’s hard to say if it affects Multi-AZ.

If you’re concerned about data integrity with MySQL replication (and you should be!) take a look at our Guide to MySQL Integrity Checking with Percona Toolkit.

Our use case is to scale reads with multiple instances

A: RDS can do this handily with Read Replicas. As long as your requirements are for vanilla replicas, this will work well for you.

To learn more about this checkout our Guide to Autoscaling MySQL on Amazon.

I don’t want to be beholden to Amazon for my database

A: Well then your choice is simpler. Locking in with Amazon RDS means when you hit a bug, your hands are a bit tied. Amazon’s DNA is as a DIY infrastructure provider, and although they’ve added support contracts to the mix, they’re not a Rackspace. At least not yet.

So there’s a tradeoff. Go with a roll your own solution where you have control over all the nuts and bolts of your technology or go with something more managed. RDS is a managed database solution, so to the extent things are automated, your hands are also tied when you hit a snag.

We want to use an alternate MySQL distribution

A: Again if you want to go with a Percona, MariaDB or Drizzle, you’re going to be using a roll your own distribution.

We want to use an exotic replication topology