Amazon RDS和EC2 with MySQL各自的优缺点是什么？

Question

我了解两者之间的几个基本区别，即：

1. EC2比较便宜。

2. RDS无需进行维护。

除了这两点之外，从RDS运行数据库相对于作为MySQL服务器扮演独立EC2服务器是否有任何优势？假设实例大小相似，两者在处理负载能力方面是否会遇到相同的限制？

为了让你更了解我的使用情况，我有一个数据库，不算太大（最大表格有100万行），只有高SELECT量。

- Macgyver

---

只是补充一下 EC2 一致备份的方法。http://alestic.com/2009/09/ec2-consistent-snapshot 我使用该工具处理一个 300GB 的服务器和大约 5,000 个数据库。目前，使用 3,000 IOPS 卷启动 MySQL 大约需要 1.2 小时，因为它从非干净关闭状态启动，所以 MySQL 必须扫描每个表。 - jozwikjp

这里有一个跨站点重复问题，网址是http://dba.stackexchange.com/questions/34525/amazon-rds-for-mysql-vs-installing-mysql-on-an-amazon-ec2-instance，其中有一些很好的答案。 - Mark Amery

Answer 1

这是一个简单的问题，但答案却相当复杂！

简而言之：如果您选择RAID0 EBS，则EC2将提供最大性能。但进行RAID0 EBS需要相当大量的维护开销，例如：

http://alestic.com/2009/06/ec2-ebs-raid

http://alestic.com/2009/09/ec2-consistent-snapshot

没有RAID0 EBS的EC2将提供低劣的I/O性能，因此这甚至不算是一个真正的选项。

RDS提供非常好（虽然不是最大）的性能。管理控制台很棒，而且升级实例很容易。高可用性和只读从库都只需要点击一下即可。它真的很棒。

简短回答：选择RDS。还在犹豫吗？选择RDS！！！如果你喜欢头疼并调整每一个小细节以获得最大性能，那么你可以考虑EC2 + EBS RAID 0。对于MySQL托管来说，原始的EC2是一个糟糕的选择。

- efalcao

---

好的回答。这正是我想要的：http://aws.typepad.com/aws/2010/10/amazon-rds-announcing-read-replicas.html - 感谢您指引我正确的方向。 - Macgyver

关于4小时维护时间窗口，有一件重要的事情需要知道，那就是你的服务器并不会每周都停机4个小时！这只是在有需要进行维护时所规定的时间。我已经运行了数月的RDS服务器，从未出现过宕机情况。 - efalcao

我们的RDS服务器运行多年，从未出现过宕机。仅有一次较大的故障（约6小时），在AWS解决问题后，一切恢复正常。(需要指出的是，这是一个多AZ实例，但它没有故障转移到备份). - cjm2671

这些问题应该是时间敏感的。许多答案和基准测试已经过时了。新的m3和i2实例具有SSD驱动器，可以杀死EBS和RDS（基本上是具有更优化的延迟基础设施的EBS）。此外，您现在可以在云端运行读取副本以滚动自己的硬件以获得超级恶心的SSD副本。简而言之，我们使用多AZ RDS作为主要备份，恢复等，然后进行副本备份以进行离线备份，然后使用带有短TTL的Route53，以防RDS故障转移在DNS方面很慢（或更糟），因此我们可以选择自己的新主机。事情已经改变了。 - Ross

@paulkon - 我们不会切换到离线副本，我们使用RDS故障转移，否则晋升等操作回到新主服务器将变得棘手。离线副本主要用于云外备份DR以及报告环境的读写分离（我们的应用程序层知道它们）。希望有所帮助。 - Ross

Answer 2

在这篇文章中，对以下几种情况进行了优秀的基准测试:

• 在小型EC2 + EBS上运行MySql
• 在小型EC2 + EBS + 调整过的MySql参数上运行MySql
• 使用小型RDS

该基准测试非常好，因为它不仅关注理想条件（只有一个线程），还涵盖更加现实的场景，即50个线程同时查询数据库。

- Andres

---

发布基准测试结果固然好，但作者诚实地承认他没有正确调整InnoDB（最重要的一个参数当然是innodb_buffer_pool_size...而他没有这样做）。 - phil_w

Answer 3

RDS并不是一个真正的高可用性系统。请仔细阅读RDS FAQ中的细则。在故障切换事件中，可能需要最多3分钟才能完成切换。此外，亚马逊会在某个时间决定需要“升级”您的RDS实例，并进行故障转移，这将使您的数据库停机“长达3分钟”（我们的经验是它可能需要更长时间）。

RDS高可用性与主 - 主或主 - 从复制非常不同，且速度较慢。它们不使用MySQL复制，而是使用某种EBS复制。因此，在故障转移情况下，它会在备份机器上挂载EBS，启动MySQL，等待MySQL完成故障恢复（希望没有出现太严重的损坏），然后进行DNS切换。

我希望这些对您的评估有所帮助。

- Jeff Whiting

---

在一个有40GB数据的数据库上添加一个读从服务器对我来说花了超过20分钟。这个加上成本和常规EC2中缺乏读从服务器以及外部不可用，对我来说几乎是不可行的。我认为RDS适合不需要真正高可用性和故障转移响应时间的小型商店。在我看来，它更多的是为了消除DBA的需求。 - Ross

好消息来了（2020年3月）。有了Aurora，情况变得更好了。虽然它仍然没有运行主-从系统，但由于他们创建了一个新的“基于云”的存储系统，故障转移现在非常快。此外，它提供快速的快照和备份。Aurora真正解决了RDS MySQL的许多缺点。 - Jeff Whiting

Answer 4

我们选择使用EC2 MySQL实例，因为我们有很高的读取量并且需要主从复制。当然，你可以启动多个RDS实例并在它们之间设置MySQL复制，但我们使用Scalr.net，它使用EC2实例自动管理这一切。

基本上，我们只需告诉Scalr我们需要多少个MySQL实例，它就会保持这些实例的运行状态，自动设置复制，处理从节点升级为主节点的自动故障转移等。它同时执行SQL转储备份和EBS卷快照备份。因此，当它需要创建新的从节点时，它会自动暂时挂载最后一个主节点快照的EBS卷以初始化从节点数据库，然后从适当的位置开始复制。这一切都是点对点的操作 :)

（不，我不是Scalr的员工。如果你不想使用他们的服务，Scalr也是开源的）

- DavidJ

---

请注意，自从我发布了上面的答案以来，亚马逊已经为RDS实例（目前仅限MySQL）引入了显式读取副本支持。 - DavidJ

Answer 5

关于维护窗口的问题。如果您使用Multi-AZ，则RDS将在另一个可用区创建一个备用副本，以便在维护期间没有停机时间，并保护自己免受区域故障。

这就是我计划在接下来的一周左右要做的事情。当然，这将会增加成本，但我还没有计算出具体的费用。

- Shin

Answer 6

EC2上的MySQL vs RDS MySQL

在EC2上使用MySQL的优势

• Amazon EC2区域间复制
• 在Amazon EC2区域之间复制快照
• MySQL EC2中的RAID 0和EBS条带化
• 可以连接超过3TB的磁盘空间（对于您的规模，您将不需要这些）。

在EC2上使用MySQL的缺点

• 与RDS相比，需要进行配置、监控和维护
• RDS提供了时点备份
• IOPS少于RDS MySQL（即使在RAID 0之后），目前为每秒10800次，而RDS MySQL为每秒12500次（16KB）

- Harish Ganesan

Answer 7

我已经试用了几个月的RDS，这里有一些问题：

1. 使用SQL Profiler很棘手。由于您无法直接连接profiler到服务器，您必须运行一些存储过程来创建一个日志文件以供分析。虽然他们提供了一些关于如何操作的建议，但它远非用户友好。我建议只有持有认证的SQL专业人员才能做这种工作。

2. 虽然Amazon备份您的实例，但您不能恢复单个数据库。我有一个具有几个独立客户特定数据库的Web应用程序，我的解决方案是启动一个运行SQL的EC2实例，附加到生产RDB数据库并导入数据，然后在EC2实例上进行备份。另一个解决方案是使用第三方工具，在应用程序服务器上创建一个庞大的SQL脚本，以便将模式和数据重新生成到某个还原点。

- Eccountable

Answer 8

我在上周末也有同样的问题。每周RDS会有4小时的停机时间进行维护。如果您可以使用EC2的微实例，那么RDS似乎更昂贵。（这对于最小流量的测试实例来说是正确的）我也无法更改RDS实例的时区，因为我没有权限。

现在我正在看另一家公司提供的基于EC2的mysqlhttp://xeround.com/。他们不使用InnoDB，而是有自己的引擎称为IDG。我刚开始调查它，但他们还处于BETA阶段，并将提供500MB的空间。

- Tihom

---

请注意，维护窗口并非每周都会有停机时间；这只是在需要进行维护时所进行的时间：http://aws.amazon.com/rds/faqs/#12另请参见@efalcao对其上面答案的评论。 - mpdaugherty

看起来非常酷，但如果你在xeround.com有任何数量的数据，那么价格真的很高。 - csharp4me