Amazon RDS: 作为云服务的 MySQL 数据库

Amazon 最近给他们的 Amazon Web Services (AWS) 平台增加了一个新的 MySQL 数据库，叫做 Amazon 关系数据库服务 (RDS)，它能和传统的 MySQL 系统一样工作。在 RDS 之前，客户在 AWS 的数据库服务上有几种选择：

• 运行在 Amazon Machine Image (AMI) 的客户自提供数据库服务
• Amazon Web 服务所拥有的 SimpleDB service

SimpleDB 是一个简单的数据存储，它缺乏一个完全成熟的关系数据库管理系统 (RDBMS) 所拥有的完善的功能，但是提供了一种可伸缩的键值存储。客户自提供数据库服务和传统的数据中心环境差不太多，由客户自己的员工负责管理数据库应用程序，包括配置，性能调优，容量管理，版本升级，打补丁和数据备份等。你可以使用和传统 MySQL 数据库连接的交互工具来以同样的方式控制它。

Amazon RDS 使得客户员工减少了很多 MySQL 的运维任务，有了它，数据库计算资源的可扩展性和性能监测都无需人为的干涉。 而数据库软件通常都由服务提供商来打补丁和备份，并且是由客户定义的保留时间段来做。可扩展性来自 AWS 所谓的“实例类”，总共有五个。你可以从一个普通的虚拟 CPU 内核以及 1.7G 的内存（被叫做“小的数据库实例” ）逐步增大到 “超大型的数据库实例”， 也就是 68G 内存和 8 个虚拟 CPU 内核，而备份存储被活动状态的数据库数据 100% 占满后，额外的存储空间是要收费的。而且数据存在另一个不同的可用区而不是该实例所在的地方。 这个和传统数据安全模型的异地数据保护的概念是类似的。

这个服务得益于灵活性，AWS 定义了一个每周 4 小时维护窗口。 这个维护窗口可以被用来为应用软件打补丁和数据备份。客户不能选择退出打补丁的过程。但是他们可以指定维护窗口在一周内何时发生。在维护窗口中，数据库实例会在特定时间段内被离线。Amazon 声明 “只有很少情况下，打补丁需要超过你的维护窗口的部分时间，即使发生也只是为了安全或者持久性相关的补丁。”

这意味着客户必须预期和计划这样一个每周发生的实例离线事件。 即使服务商表示不太可能用完四个小时的时间，但客户也会预期最差的情况，每周要有四个小时的实例离线时间。对于能够接受一个相对短时间的数据库实例不可用的客户，按计划的关闭时间而只有最小可能的影响的方案也许能够被接受。但有一些客户没有这样选择的自由。他们必须保证服务 24x7 可用，即使在每周的维护窗口运行的时候也一样。在传统的数据库部署中数据库复制技术常常被用来达到高可用性。复制技术能不能也用到 RDS 中，从而让客户能够为不同的数据库实例指定不同的维护时机呢? 比如，如下几种情况可能吗？

• 2 个或更多的实例运行在 master-slave 模式？
• 2 个实例运行在 master-master 模式？
• 2 个或更多的实例运行在 cluster 模式？

现在还没有很明确的答案。 在 RDS 服务细节页面 的“即将推出的新特性” 一节中，Amazon 预期数据复制可用性的选择将会是：

提供高可用性 --对于想要超出 Amazon RDS 自动备份之外灵活性的那些开发者和商业人士，将不需要对此额外付费。有了高可用性的支持，他们能够很容易并且在成本有效的情况下在多个可用区之间同步复制数据库实例，来防止出现单一存储导致的失败。

看起来这将会通过多个可用区为代价来来解决可用性问题。而解决可用性的传统技术如 master-slave 和 master-master 模型在这一点上并不能起到作用。

查看英文原文： http://www.infoq.com/news/2009/12/amazon-rds-cloud-db