amazon ec2 mysql_Amazon RDS for MySQL与在Amazon EC2实例上安装MySQL

我一般都是AWS的忠实粉丝…但是RDS,不是那么多.

@RolandoMySQLDBA已经指出了一些非常好的反对它.

与EC2上的MySQL相比,我在RDS中看到的唯一优势是能够执行点击快照,克隆和时间点恢复,但这些优势还不足以弥补失去控制和灵活性的问题.大多数人肯定不能证明价格更高. RDS在某些方面很性感,但你不能最终相信你最终无法解决的问题,因为你无法找到所有活动部件.

我不喜欢没有SUPER特权.我不喜欢无法拖尾错误日志.我不喜欢无法在我的数据库服务器上运行“top”或“iostat”来查看核心和驱动器如何享受负载.我不喜欢无法访问联合存储引擎.我不喜欢支付热备用(多AZ)备份主机的想法,我甚至无法将其用作只读副本.当然,有完全合理的解释为什么所有这些约束都必须到位,以便MySQL成功打包并作为RDBMS-in-a-box出售.唯一的问题是,RDBMS-in-a-box“解决”了我没有的一系列问题……并且妨碍了我,造成了新的问题.

但对我来说,使用RDS的绝对优势是完全无法访问二进制日志和复制. Binlogs,特别是基于行的,对于轻微灾难来说是一个很棒的恢复工具,但如果你无法访问它们,它们对你没有任何帮助.想要在办公室配置内部部署服务器作为RDS中生产数据库的只读副本吗？如果您的RDS中的数据发生了不可想象的事情,那么可以采取本地备份,进行报告,手头进行灾难恢复吗？这是一个同时显而易见的想法.

哎呀,抱歉,无法直接访问复制.当然,您可以支付读取副本…但仅作为其他RDS实例.在我的书中不是一个价值主张.

更新：MySQL 5.6的RDS的一个重大变化

我仍然喜欢运行我自己的服务器(即使在EC2中)而不是运行RDS,原因有很多,包括缺乏对User-Defined Functions的支持,无法使用Federated Storage Engine,以及无法使one extra connection可用于紧急访问. ..但是……

亚马逊已经在MySQL 5.6 for RDS上做了重大改变,这消除了我的一个主要反对意见 – 也许是我最大的反对意见：现在可以访问二进制日志,你可以将非RDS实例作为从属运行,或者将其他实用程序连接到读取binlog流的服务器.

正式地说,文档表明它们正在暴露这个,以便您可以设置一个从站进行实时迁移 – 使用mysqldump从现有RDS实例同步外部未来主服务器,然后将其连接到RDS作为slave通过复制流获取更新的实时源,直到您的应用程序迁移到新主服务器 – 但非正式地,只要您不希望它们支持您,您就可以持续执行此操作…对我来说,似乎是合理的.

这是在in a recent Webinar,在56:45左右开始的对话中确认的：

“You can keep it in a replicated state indefinitely…

“…as long as you take the responsibility to maintain the replication…”

“We are not preventing you from doing ongoing replication if that’s what you want.”

这个新功能足以让我放弃我在面向公众的网站支持MySQL实例中使用RDS的全面反对意见,我们不会使用FEDERATED或其他一些内容.

所以我仍然不赞成它,但我不再反对它,因为拥有二进制日志的实时流使我最终实时控制数据并确保没有交易的责任在灾难性的停电中迷失了我的回归,因为我作为DBA重新掌控了 – 这正是我想要的.让第三方供应商指责或提起诉讼或其他任何事情,如果它丢失在黑匣子内的黑洞中,则不会丢失您丢失的数据.

管理层似乎喜欢RDS的“想法”并且不反对成本差异,因此我们现在推出所有新的网站,其中包含RDS.

我承认,点击时间点恢复是RDS中的一个很好的功能…它不会改变或破坏你现有的机器 – 相反,它会启动一个全新的实例,使用备份最接近所选时间点,然后应用必要的binlog以使新机器前进到您指定的时间点.

与此相关,但在另一个方向,现在也可以使用类似的策略将实时MySQL数据库迁移到RDS …您可以连接RDS主机(可能,通常,这将是新部署的实例)作为现有系统的从属设备,以便RDS实例在您迁移到数据时具有实时版本的数据.与访问RDS binlogs进行外向复制(仅适用于5.6)不同,inward replication is supported in RDS以5.5.33和5.6.13开头.