在工作中，我们将所有Web服务器托管在Amazon EC2上，通常使用与Apache Web服务器安装在同一盒子上的MySQL数据库，并在localhost上与它们进行通信。现在，我们需要将数据库迁移到我们系统之一的自己的服务器上。我可以选择两种解决方案：使用Amazon RDS，或者只是启动一个新的Amazon EC2盒并在其上安装MySQL。

RDS是与EC2相同的公司提供的专用数据库服务好像应该是明显更好的选择。但是，当我查看这两个选项的价格时（请参阅http://aws.amazon.com/ec2/pricing和http://aws.amazon.com/rds/pricing），似乎RDS服务器的成本几乎是对于具有相同规格的机箱，其容量是EC2服务器的两倍。 ，我完全看不出使用RDS代替EC2的任何理由。但是，似乎我可能遗漏了一些大的东西，因为如果我做对了，没有人会使用RDS。我到底缺少什么？与在EC2实例上安装自己的数据库相比，RDS有何优势？

评论

值得注意的是，自从我问了这个问题以来，EC2和RDS之间的价格比率已经发生了很大变化。 EC2上的实例正常运行时间仍然比较便宜，但超过RDS价格的三分之二；从EC2迁移到RDS（反之亦然）不再意味着将服务器费用增加一倍（或减半）。 （当然，根据您的情况，这可能仍然值得关注。）

#1 楼

总的来说，我是AWS的忠实拥护者，但是RDS却不多。

@RolandoMySQLDBA指出了一些相当不错的观点。

与EC2上的MySQL相比，我在RDS中看到的唯一优势是指向和单击快照的能力。 ，克隆和时间点恢复，但这些还不足以弥补失去控制和灵活性的不足，并且最肯定地不能证明价格会更高。 RDS在某些方面很性感，但是您最终不能相信自己最终无法解决的问题，因为您无法接触到所有的运动部件。

我不喜欢没有SUPER特权。我不喜欢无法跟踪错误日志。我不喜欢无法在数据库服务器上运行“ top”或“ iostat”来查看核心和驱动器如何承受负载。我不喜欢无法访问联合存储引擎。我不喜欢购买热备用（多可用区）备份主计算机，而我什至无法利用它作为只读副本。当然，有完全合理的解释，为什么必须对所有这些约束都加以适当设置才能使MySQL成功打包并作为RDBMS-in-a-box出售。唯一的问题是，RDBMS-in-a-box可以“解决”我所没有的一系列问题……并妨碍了我的工作，从而引发了新的问题。

但是，对我而言，使用RDS的绝对优势在于完全缺乏对二进制日志和复制的访问权限。 Binlog，尤其是基于行的Binlog是用于小型灾难的出色恢复工具，但如果您无法访问它们，则对您没有帮助。是否想在办公室中将本地服务器配置为RDS中生产数据库的只读副本？如果驻留在RDS中的数据发生不可思议的事情，则可以从中进行本地备份，进行报告并进行灾难恢复吗？这是一个显而易见而又辉煌的想法。

糟糕，抱歉，无法直接访问复制。当然，您可以支付只读副本的费用……但只能作为其他RDS实例的费用。在我的书中，这不是一个价值主张。

更新：针对MySQL 5.6的RDS中的一项重大更改

我仍然更喜欢运行自己的服务器（甚至在EC2中），而不是运行RDS出于多种原因，包括缺乏对用户定义功能的支持，无法使用联合存储引擎以及无法为紧急访问提供一个额外的连接...但是...

Amazon在RDS的MySQL 5.6中进行了重大更改，消除了我的主要反对意见之一-也许是我最大的反对意见：二进制日志现在可以访问，并且您可以将非RDS实例作为从属实例运行，或者将其他实用程序连接到读取binlog流的服务器。

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html

正式地，该文档表明他们正在公开此信息，以便您可以设置从属服务器以进行实时迁移-您可以同步使用mysqldump从现有RDS实例中统治未来的主服务器，然后将其作为从服务器连接到RDS，以通过复制流获得实时更新，直到您的应用程序迁移到新的主服务器上-但非正式地，您可以在只要您不希望他们支持您...就我而言，这似乎是合理的。

在最近的一次网络研讨会上，在大约56:45开始的一次对话中证实了这一点：


“您可以将其无限期地保持在复制状态。 ..

“ ...只要您负责维护复制...”

“我们不会阻止您进行正在进行的复制，如果那样的话您想要的。“


这项新功能足以让我完全反对在面向公众的网站支持的MySQL实例中使用RDS，在这种情况下，我们根本不使用FEDERATED或其他任何东西。

因此，我仍然不赞成它，但是我不再反对它，因为拥有二进制日志的实时流最终使我最终恢复了对数据的实时控制，确保我在灾难性中断中不会丢失任何事务的责任又回到了我身边，因为作为DBA的我已重新掌控一切-这正是我想要的。如果第三方供应商指责或提出诉讼或以其他方式起诉，则丢失的数据不会消失在黑匣子内的黑洞中。

管理似乎就像RDS的“理想”一样，并且不反对成本差异，因此我们现在启动所有带有RDS的新网站。

点对点时间点恢复，我承认，它是RDS中的一个不错的功能...它不会改变或破坏您现有的计算机-而是完全启动了新实例，使用时间上最接近所选时间点的备份，然后应用必要的binlog将新机器带入您指定的时间点。

与此相关，但是从另一个方向来说，现在也可以使用类似的策略将实时MySQL数据库迁移到RDS中……您可以连接RDS主服务器（大概是，这将是一个新部署的实例）作为现有系统的从属，以便RDS实例在迁移到该实例时具有实时数据版本。与仅用于5.6的对RDS二进制日志进行向外复制的访问不同，RDS从5.5.33和5.6.13开始支持向内复制。

评论

我可以知道您如何使用联合存储引擎吗？

–巴拉特·哈特里（Bharat Khatri）
15年8月16日在9:42

#2 楼

如果扩展DB Server并非您的最佳选择，那么可以使用Amazon RDS，因为它附带了所有功能。那些只需要适度的HA，备份和向外扩展的用户将受益匪浅。

另一方面，如果您想扩展硬件，那么RDS则无济于事。如果您想扩大MySQL的功能怎么办？不幸的是，对于许多方面来说，这是不可能的。

例如，您是否知道在所有七个（7）RDS服务器模型中都有两个字段？


max_connections
innodb_buffer_pool_size

请注意以下两个选项的图表：

MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)


具有SUPER特权，无法直接访问my.cnf。鉴于此，为了更改my.cnf的启动选项，必须首先创建一个基于MySQL的数据库参数选项列表，然后使用RDS CLI (Command Line Interface)更改所需的选项。然后，您必须执行此操作以导入新选项：


创建自定义数据库参数组（称为MySettings）
下载RDS CLI并使用AWS设置配置文件凭据
执行以下操作：./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"

使用数据库参数选项列表进行修改MySettings

重新启动MySQL RDS实例

使用API更新单个变量并强制重启RDS实例以实现更改？要限制任何一个选项，这是一个非常痛苦的过程。

如果要扩展MySQL，请使用EC2。然后，您可以像往常一样习惯了，按自己的喜好进行调整。