6

We currently run MySQL on EC2, and we have been for some time. I like the idea of simplified backups, recovery, and fail-over, and I'm really tempted by the apparent ease of using RDS instead of EC2. I've started the migration from EC2 to RDS, but as I work through the migration I keep wondering if I'm doing the right thing.

I've read people hinting against using Amazon RDS for MySQL databases, but I haven't found a concise explanation of the disadvantages of RDS.

Can someone help me understand why I should NOT move to RDS, but instead keep my data in EC2?

Our database is approximately 30GB of data, which is mostly from an 18-million row table and a 40-million row table in a single InnoDB database.

Any thoughts are much appreciated. Thanks!

Travis Austin
  • 439
  • 5
  • 14
  • 1
    While you gain some automation, you do give up some control. Its a tradeoff that is not worth it to everyone. – datasage Aug 16 '13 at 16:35

3 Answers3

3

This is mainly an issue with the DBA of the team.

RDS is aimed at removing most of the repetitive and boring tasks of DBA (mainly multi-AZ replication, backup, restore, patching...). This part can be even 70% of the time spent by DBAs.

On the other hand some tasks that DBA can do if they are running the DB on their instance (for example, on EC2), are not accessible with RDS, as they don't have ROOT on the RDS instance.

If your DBA (and your use case) can benefit from the heavy lifting and not suffer from the reduced privileges, you should certainly consider RDS.

Guy
  • 12,388
  • 3
  • 45
  • 67
  • In this case, I'm the developer and the DBA. Although I'm not a full-time DBA, and it's not my top expertise, I'm far from inexperienced in MySQL administration. I'm trying to learn what things I may not think about now that may inhibit my abilities later. – Travis Austin Aug 17 '13 at 15:55
  • 1
    Then I'd suggest you go for it. I'm also the sole resident sysadmin and would rather outsource the crucial but tedious DBA tasks where I can. I have yet to strike an issue where not having complete root access was a problem, but a whole lot of distraction (and some stress) went away with backups, failovers, capacity management and upgrades managed by RDS. It's not as though it's a do or die decision: if you find something later on that you can't do, you can always fire up your own MySQL box again. I'm betting you won't need to. – ianjs Aug 18 '13 at 05:51
3

We manage a database of 200GB in twentyish tables in RDS. In my experience, using RDS saves a ton of time, while the drawbacks which do exist are minor and can be worked around. Overall the time RDS has saved is vastly greater than that taken up by any headaches. However, two that I have encountered are:

  1. You can't set global variables as a root user in RDS- you have to set them in a parameter group and then apply that to the database, which is harder than "SET GLOBAL" but offers other benefits.

  2. You can't dump into an out-file because you don't have access to the RDS filesystem. See this question. However as noted in that question there are workarounds.

Community
  • 1
  • 1
rjgage
  • 53
  • 1
  • 5
0

The only thing that you would give up by using RDS, are the logs, unfortunately RDS doesn't provide a full set of logs which sometimes are vital for debugging. If you can live without them and you have a strong testing before going to production then RDS is the way to go.

Alexandru Kiss
  • 17
  • 2