I run a fairly busy but normal implementation of MySQL on Amazon EC2 - 1 Master server and 3 read only slaves, with about 50GB of data spread between our portal database, a mediawiki instance, a forums database, a large dataset data for FCC license data, and a large core content database.
In initial testing of RDS after their recent updated release (we were excited about it!), we've found that RDS performance is significantly lower than running your own MySQL implementation with your storage being a 4 disk RAID-0 implementation on EBS. I suspect RDS uses a single EBS disk which is probably the root of the performance issues.
We didn't run actual benchmarks, but we quickly determined that RDS wasn't going to cut it from a performance perspective. In some cases, queries that take 3 seconds on our own MySQL implementation took well over 20 secs on RDS.
I see the value of RDS for many use cases, but in our case the performance of RDS is so significantly lower for a high-traffic use case that it wasn't going to work out for us.
Now, we still see performance problems when running MySQL on RAID-0 EBS - so we're considering going to an ephemeral disk implementation on EC2 and letting a single slave run on EBS and then snapshot from there often. If we lose an instance, we could restore from a snapshot quite quickly (within minutes).
In any case, regardless of our approach, RDS isn't going to be a part of it for now.
Assuming you use InnoDB, is your innodb_buffer_pool_size big enough to hold your data (or a significant amount of it)?
It's by far the most important setting to get speedy reads, which form 95% of the queries in our case.
When you did the testing, did you warm up the RDS instance before, for example by running a number of common queries? It naturally takes a while after booting until MySQL can make efficient use of caches and buffers.
I'm not sure if instance-local storage will give you better performance compared to EBS. From the EBS page: "The latency and throughput of Amazon EBS volumes is designed to be significantly better than the Amazon EC2 instance stores in nearly all cases."
There is a problem with the recovery approach you described: as far as I know you can't use an EBS snapshot to populate local storage on a new instance, so you would be forced to use EBS for the new master. Promoting the slave to be the new master would be the better approach, with less downtime and data loss, provided that MySQL replication didn't break unnoticed.
In initial testing of RDS after their recent updated release (we were excited about it!), we've found that RDS performance is significantly lower than running your own MySQL implementation with your storage being a 4 disk RAID-0 implementation on EBS. I suspect RDS uses a single EBS disk which is probably the root of the performance issues.
We didn't run actual benchmarks, but we quickly determined that RDS wasn't going to cut it from a performance perspective. In some cases, queries that take 3 seconds on our own MySQL implementation took well over 20 secs on RDS.
I see the value of RDS for many use cases, but in our case the performance of RDS is so significantly lower for a high-traffic use case that it wasn't going to work out for us.
Now, we still see performance problems when running MySQL on RAID-0 EBS - so we're considering going to an ephemeral disk implementation on EC2 and letting a single slave run on EBS and then snapshot from there often. If we lose an instance, we could restore from a snapshot quite quickly (within minutes).
In any case, regardless of our approach, RDS isn't going to be a part of it for now.