This is a simple question with a very complicated answer!
In short: EC2 will provide maximum performance if you go with a RAID0 EBS. Doing RAID0 EBS requires a pretty significant amount of maintenance overhead, for example:
EC2 without RAID0 EBS will provide crappy I/O performance, thus it's not even really an option.
RDS will provide very good (though not maximum) performance out of the box. The management console is fantastic and it's easy to upgrade instances. High availability and read only slaves are a click away. It's REALLY awesome.
Short answer: Go with RDS. Still on the fence? Go with RDS!!! if you enjoy headaches and tuning every last little bit for maximum performance, then you can consider EC2 + EBS RAID 0. Vanilla EC2 is a terrible option for MySQL hosting.
In this post there is an excellent benchmark between:
Running MySql on a Small EC2 + EBS
Running MySql on a Small EC2 + EBS + adjusted MySql parameters
A Small RDS
The benchmark is very good since it is not focused only in ideal conditions (only one thread) but also in more realistic scenarios, with 50 threads hitting the database.
RDS高可用性与主-主或主-从复制有很大不同，并且速度慢得多。他们不使用 mysql 复制，而是使用某种 ebs 复制。因此，在故障转移情况下，它将在备份计算机上安装 ebs，启动 mysql，等待 mysql 进行故障恢复（希望没有任何损坏），然后进行 dns 切换。
我希望这对您的评估有所帮助。
RDS is not really a high availability system. Read the fine print in the RDS faq. During a failover event it can take up to 3 minutes to failover. Additional amazon will decide it needs to "upgrade" your rds instance and do a failover at that point which will take your database down for "up to 3 minutes" (our experience is that it can take a longer than that).
RDS high availability is very different than master - master or master - slave replication and is much slower. They don't use mysql replication but uses some kind of ebs replication. So in a failover situation it will mount the ebs on the backup machine, start mysql, wait for mysql to do failure recover (hopefully nothing got corrupted too bad), then do a dns switch.
We chose to use EC2 MySQL instances because we have a high read volume and need master-slave replication. Of course, you can spin up multiple RDS instances and setup MySQL replication between them yourself, but we use Scalr.net, which manages that for you using EC2 instances.
Basically, we just tell Scalr how many MySQL instances we want at it keeps them up, automates the setup of replication, handles automatic failover of slave promotion to master if the master gets terminated etc. It does both SQL dump backups and EBS volume snapshots of the master. So, when it needs to create a new slave, it automatically temporarily mounts an EBS volume of the last master snapshot to initialize the slave DB, then starts replication from the appropriate point. All point and click :) (and no, I don't work for Scalr or anything. Scalr is available as Open Source if you don't want to use their service)
Regarding the maintenance window question. If you use Multi-AZ then RDS will create a standby replica in another availability zone so that there's no down time for maintenance and you protect yourself against a zone failure.
That's what I'm planning to do in the next week or so. Of course it's going to cost you more but I haven't worked that bit out yet.
I have been trying out RDS for a few months and here are some issues I have:
Using SQL profiler is tricky. Since you cannot connect profiler directly to the server, you have to run some stored procedures to create a log file that you can analyze. While they offer some suggestions about how that is done, it is far from user friendly. I would only recommend that you have a certified SQL professional do this kind of work.
while Amazon backs up your instance, you cannot restore an individual database. I have a web app with several separate customer-specific databases and my solution was to launch an EC2 instance with SQL running on it to attach to the production RDB database and import the data and then back it up on the EC2 instance. The other solution was to use a 3rd party tool that creates a massive SQL script (on the app server) that will recreate the schema and populate the data back to a restore point.
I had the same question this weekend. There is a 4 hour downtime window per week for RDS where they do maintenance. RDS seemed more expensive if you can get away with a micro instance of EC2. (This is true of test instances which has minimum traffic) I also wasn't able to change the timezone of the RDS instance because I dont have permission.
I am now actually looking at http://xeround.com/ which is mysql on EC2 by another company. They do not use InnoDB, instead they have their own engine called IDG. I am just starting to investigate that but they are in BETA and will give 500MB of space.
发布评论
评论（8）
这是一个简单的问题，但答案却非常复杂！
简而言之：如果您使用 RAID0 EBS，EC2 将提供最大性能。执行 RAID0 EBS 需要相当大量的维护开销，例如：
http://alestic。 com/2009/06/ec2-ebs-raid
http://alestic.com/2009/06/ec2-ebs-raid com/2009/09/ec2-consistency-snapshot
没有 RAID0 EBS 的 EC2 将提供蹩脚的 I/O 性能，因此它甚至不是一个真正的选择。
RDS 将提供非常好的（尽管不是最高的）开箱即用性能。管理控制台非常棒，并且很容易升级实例。高可用性和只读从站只需点击一下即可。真的太棒了。
简短的回答：选择 RDS。还在围墙吗？与RDS一起去吧！如果您喜欢头痛并喜欢调整每一点以获得最大性能，那么您可以考虑 EC2 + EBS RAID 0。对于 MySQL 托管来说，Vanilla EC2 是一个糟糕的选择。
This is a simple question with a very complicated answer!
In short: EC2 will provide maximum performance if you go with a RAID0 EBS. Doing RAID0 EBS requires a pretty significant amount of maintenance overhead, for example:
http://alestic.com/2009/06/ec2-ebs-raid
http://alestic.com/2009/09/ec2-consistent-snapshot
EC2 without RAID0 EBS will provide crappy I/O performance, thus it's not even really an option.
RDS will provide very good (though not maximum) performance out of the box. The management console is fantastic and it's easy to upgrade instances. High availability and read only slaves are a click away. It's REALLY awesome.
Short answer: Go with RDS. Still on the fence? Go with RDS!!! if you enjoy headaches and tuning every last little bit for maximum performance, then you can consider EC2 + EBS RAID 0. Vanilla EC2 is a terrible option for MySQL hosting.
在这篇文章中有一个很好的基准之间：
该基准测试非常好，因为它不仅关注理想条件（仅一个线程），而且还关注更现实的场景，有 50 个线程访问数据库。
In this post there is an excellent benchmark between:
The benchmark is very good since it is not focused only in ideal conditions (only one thread) but also in more realistic scenarios, with 50 threads hitting the database.
RDS并不是真正的高可用性系统。阅读 RDS 常见问题解答中的细则。在故障转移事件期间，故障转移最多可能需要 3 分钟。其他亚马逊将决定需要“升级”您的 rds 实例并在此时进行故障转移，这将使您的数据库停机“最多 3 分钟”（我们的经验是，它可能需要更长的时间）。
RDS高可用性与主-主或主-从复制有很大不同，并且速度慢得多。他们不使用 mysql 复制，而是使用某种 ebs 复制。因此，在故障转移情况下，它将在备份计算机上安装 ebs，启动 mysql，等待 mysql 进行故障恢复（希望没有任何损坏），然后进行 dns 切换。
我希望这对您的评估有所帮助。
RDS is not really a high availability system. Read the fine print in the RDS faq. During a failover event it can take up to 3 minutes to failover. Additional amazon will decide it needs to "upgrade" your rds instance and do a failover at that point which will take your database down for "up to 3 minutes" (our experience is that it can take a longer than that).
RDS high availability is very different than master - master or master - slave replication and is much slower. They don't use mysql replication but uses some kind of ebs replication. So in a failover situation it will mount the ebs on the backup machine, start mysql, wait for mysql to do failure recover (hopefully nothing got corrupted too bad), then do a dns switch.
I hope this helps you with you evaluation.
我们选择使用EC2 MySQL实例，因为我们的读取量很大，需要主从复制。当然，您可以启动多个 RDS 实例并自行在它们之间设置 MySQL 复制，但我们使用 Scalr.net，它使用 EC2 实例为您管理这些复制。
基本上，我们只是告诉 Scalr 我们需要多少个 MySQL 实例来保持它们的运行，自动设置复制，在主服务器终止时处理从服务器升级到主服务器的自动故障转移等。它会执行 SQL 转储备份和 EBS 卷快照主人。因此，当它需要创建新的从属时，它会自动临时挂载最后一个主快照的EBS卷来初始化从属数据库，然后从适当的点开始复制。全部点击：）
（不，我不为 Scalr 或任何其他公司工作。如果您不想使用他们的服务，Scalr 可以开源）
We chose to use EC2 MySQL instances because we have a high read volume and need master-slave replication. Of course, you can spin up multiple RDS instances and setup MySQL replication between them yourself, but we use Scalr.net, which manages that for you using EC2 instances.
Basically, we just tell Scalr how many MySQL instances we want at it keeps them up, automates the setup of replication, handles automatic failover of slave promotion to master if the master gets terminated etc. It does both SQL dump backups and EBS volume snapshots of the master. So, when it needs to create a new slave, it automatically temporarily mounts an EBS volume of the last master snapshot to initialize the slave DB, then starts replication from the appropriate point. All point and click :)
(and no, I don't work for Scalr or anything. Scalr is available as Open Source if you don't want to use their service)
关于维护窗口问题。如果您使用多可用区，则 RDS 将在另一个可用区中创建备用副本，这样就无需停机进行维护，并且可以保护自己免受区域故障的影响。
这就是我计划在下周左右做的事情。当然，这会花费更多，但我还没有解决这个问题。
Regarding the maintenance window question. If you use Multi-AZ then RDS will create a standby replica in another availability zone so that there's no down time for maintenance and you protect yourself against a zone failure.
That's what I'm planning to do in the next week or so. Of course it's going to cost you more but I haven't worked that bit out yet.
EC2 上的 MySQL 与 RDS MySQL
EC2 上的 MySQL 的优势
Amazon EC2 区域间复制
跨 Amazon EC2 区域的副本快照
MySQL EC2 中具有 EBS 条带化的 RAID 0
可以在 EC2 上的 MySQL 上附加超过 3TB 的磁盘空间（您不需要这个空间）。
EC2 上 MySQL 的缺点
与 RDS 相比配置、监控和维护 RDS
中可用的时间点备份
IOPS 低于 RDS MySQL（即使在 RAID 0 后），目前，EC2 上的 MySQL 具有 6 个磁盘为 10800，而 12500 RDS MySQL 上的 IOPS 16KB
MySQL on EC2 vs RDS MySQL
Advantages of MySQL on EC2
Amazon EC2 Inter Region Replication
Copy Snapshots across Amazon EC2 regions
RAID 0 with EBS Striping in MySQL EC2
More than 3TB of Disk space ( You will not need this for your size) can be attached on MySQL on EC2.
Disadvantages of MySQL on EC2
Configuration, Monitoring and Maintenance compared to RDS
Point in time backups available in RDS
IOPS lesser than RDS MySQL ( even after RAID 0) currently, 10800 with 6 disks for MySQL on EC2 whereas 12500 IOPS 16KB on RDS MySQL
我已经尝试 RDS 几个月了，以下是我遇到的一些问题：
使用 SQL 探查器很棘手。由于您无法将探查器直接连接到服务器，因此您必须运行一些存储过程来创建可以分析的日志文件。虽然他们提供了一些关于如何完成此操作的建议，但它远非用户友好。我只建议您让经过认证的 SQL 专业人员来完成此类工作。
当 Amazon 备份您的实例时，您无法恢复单个数据库。我有一个包含多个单独的客户特定数据库的 Web 应用程序，我的解决方案是启动一个运行 SQL 的 EC2 实例，以附加到生产 RDB 数据库并导入数据，然后将其备份到 EC2 实例上。另一个解决方案是使用第三方工具来创建大量 SQL 脚本（在应用程序服务器上），该脚本将重新创建架构并将数据填充回还原点。
I have been trying out RDS for a few months and here are some issues I have:
Using SQL profiler is tricky. Since you cannot connect profiler directly to the server, you have to run some stored procedures to create a log file that you can analyze. While they offer some suggestions about how that is done, it is far from user friendly. I would only recommend that you have a certified SQL professional do this kind of work.
while Amazon backs up your instance, you cannot restore an individual database. I have a web app with several separate customer-specific databases and my solution was to launch an EC2 instance with SQL running on it to attach to the production RDB database and import the data and then back it up on the EC2 instance. The other solution was to use a 3rd party tool that creates a massive SQL script (on the app server) that will recreate the schema and populate the data back to a restore point.
这个周末我也有同样的问题。 RDS 每周有 4 小时的停机时间进行维护。如果您可以使用 EC2 的微型实例，RDS 似乎会更昂贵。 （对于流量最小的测试实例来说也是如此）我也无法更改 RDS 实例的时区，因为我没有权限。
我现在实际上正在查看 http://xeround.com/ 这是另一家公司在 EC2 上的 mysql。他们不使用InnoDB，而是有自己的引擎，称为IDG。我刚刚开始调查，但他们处于测试阶段并且将提供 500MB 的空间。
I had the same question this weekend. There is a 4 hour downtime window per week for RDS where they do maintenance. RDS seemed more expensive if you can get away with a micro instance of EC2. (This is true of test instances which has minimum traffic) I also wasn't able to change the timezone of the RDS instance because I dont have permission.
I am now actually looking at http://xeround.com/ which is mysql on EC2 by another company. They do not use InnoDB, instead they have their own engine called IDG. I am just starting to investigate that but they are in BETA and will give 500MB of space.