深入探讨 Amazon RDS MultiAZ 和两份可读的备用实例

关键要点

在这篇文章中，我们将探讨 Amazon Relational Database Service (Amazon RDS) 的 MultiAZ 数据库集群配置，重点是 MySQL 和 PostgreSQL 数据库实例的高可用性和持久性。同时，我们还将讨论其架构的复杂性以及日常操作中可能遇到的问题。

在本文中，我将讨论 Amazon RDS MultiAZ 数据库集群配置，特别是针对 RDS for MySQL 和 RDS for PostgreSQL 的数据库实例。

创建 MultiAZ 数据库集群时，Amazon RDS 会维护一个主实例和两份可读的备用数据副本。如果主副本出现问题，Amazon RDS 会自动将请求转移到可读备用副本，以确保数据的持续可用性。这两份可读副本存放在不同的可用区 (Availability Zones) 中，这样可以显著降低三份数据副本在大多数情况下同时被干扰的可能性。合理的数据管理、简单的重新配置以及对副本的可靠用户访问，是满足客户环境高可用性需求的关键。

RDS MultiAZ DB 集群的基本设计

RDS MultiAZ 数据库 (DB) 集群是一种包含三个节点的集群配置，旨在提供高可用性、减少写延迟以及在需读副本的用户中实现成本效益。该集群管理一个主数据库实例和两个备用实例的跨三可用区的数据复制。主数据库实例提供读写能力，而备用数据库实例则在主实例故障时充当自动故障转移目标，并提供读能力。

新的 MultiAZ 集群部署利用数据库引擎的原生复制，同时使用本地存储的 NVMe 实例类型及附加的 Amazon EBS 磁盘，以提供可持续的高可用性、性能和吞吐量。与现有的 RDS MultiAZ 架构相同，Amazon RDS 会自动检测和管理故障转移，以确保高可用性，并自动化配置、监控和维护 MultiAZ 数据库的繁琐管理任务，让你能专注于应用的开发。

以下示意图展示了 MultiAZ DB 集群中的三个 RDS DB 实例：中间的主实例，以及左右两边的两份可读备用实例。在这个例子中，DNS 将应用程序指向位于可用区 (AZ1) 的主数据库实例，即写入终端，能够处理读写流量，并为存储在 AZ1 中的数据库提供主要数据副本。应用程序通过写入终端向主实例写入数据后，数据库复制过程会确保写入数据能够传递到备用实例虚线路径。

图 1：MultiAZ DB 集群的写入路径示意图

在正常运行期间，复制过程中的三个活动 Amazon RDS 实例各自管理一个数据库存储卷并持有数据的完整副本。任何时刻，每个实例都扮演特定的角色。其中一个是主实例，提供外部终端，并同时处理读写流量，而另外两个是备用实例，作为次要实例，半同步写入所有来自主实例的数据。半同步复制意味着，在其中一个备用副本确认已收到事务之前，主实例不会向客户端确认提交。这种行为确保事务至少在两个机器上持久化，同时在稳态中减少感知的写延迟，因为客户体验到的延迟是两者中的最佳。

如果出现可用性问题，RDS 会自动将一个备用实例提升至主角色，并通过重定向或 DNS 传播恢复可用性。这一事件被称为故障转移。重定向到新主实例是通过 DNS 实现的。客户 DNS 查询结果中的相关 IP 地址记录具有非常低的生存时间TTL值。低 TTL 旨在抑制名称到地址信息的长期缓存，这使得客户端能够更快地更新信息，从而更及时地接收 DNS 重定向的变更。

通常情况下，故障转移事件很少发生，但它们确实会发生。在 Amazon RDS 发现问题时，故障转移是自动的。你也可以通过 Amazon RDS API 或控制台手动发起故障转移。有关更多信息，请参阅 手动故障转移 MultiAZ DB 集群。

复制过程外部可见性有限，因此不能作出一些更具战略性的决策。例如，它对用户连接问题、本地或区域性中断以及其对等数据库实例的状态并不了解。为此，每个实例都有一个监控系统，能够访问更为关键的信息，并定期查询实例的状态。在适当的情况下，监控系统会采取措施，确保满足可用性和性能需求。后文中我将更详细地讨论监控系统。

MultiAZ DB 集群所提供的可用性和持久性改善，成本极低。在正常使用场景中，复制层是连接的，半同步写操作发生在可读备用数据库存储卷上。可读备用实例和卷位于不同的、地理上相隔较远的可用区。评估结果 显示写入速度可以提高两倍，与 MultiAZ 实例部署相比性能更优。然而，实际在真实场景中的影响取决于客户的工作负载。

该设计使 AWS 提供超过 9995 可用性的服务级别协议 (SLA)。想了解更多，请查看 Amazon RDS 服务级别协议。

实现的复杂性

你可能会认为，存储卷复制设施的设计相当简单和直接。然而，实际的实现相当复杂。这是因为它必须考虑到三台联网、独立实例和存储卷可能经历的所有情况，同时必须应对一个不断变化且有时会干扰的环境。

正常的持续复制假设所有设备都处于合理的工作状态并表现良好：DB 实例可用、例行实例监控正常、存储卷可用，网络性能如预期那样。但是，当这些组成部分其中之一或多个无法正常工作时会发生什么？让我们检查一些潜在的问题及其解决方案。

连接问题和同步

有时，主实例和备用实例之间无法连接，可能是由于问题或故意的管理操作。此时无法进行持续复制，并且长时间等待连接恢复是不可接受的。当连接丢失时，实例会等待监控系统的决策。当监控系统检测到这种情况时，它会指示一个备用实例担任主角色故障转移并继续运行，且不依赖于复制。这时数据只有一份副本，而另一份副本逐渐变为陈旧。在 MultiAZ 实例部署架构中，备用实例是冷备用实例，数据复制是在数据库存储层进行的。而在 MultiAZ DB 集群部署中，我们利用数据库引擎的原生数据复制，备用实例的数据库引擎是热备的。故障转移时间主要受备用实例的应用延迟和 DNS 传播时间的影响，通常在 20 秒内完成。

RDS MultiAZ DB 集群的另一个架构变化是，从一个多租户、单节点的集中监控和恢复系统转变为单租户、基于共识的监控和恢复解决方案，运行在与数据库相同的 MultiAZ DB 集群节点上。这使我们能够更高频率地监控数据库健康状态，并更快速地启动故障转移。原生数据复制允许我们迅速进行故障转移，无需等待数据库引擎启动时间和崩溃恢复，从而将 Amazon RDS 的可用性目标提高到 9995，相比之下，单可用区部署只能提供 995 的 SLA。此外，连接问题会通过自动检测系统快速调查，问题通常能够迅速纠正。如果问题持续超过最低时间，则会触发操作员干预警报。因此，我们预计大多数连接问题的持续时间相对较短，三台实例很快会恢复连接。

当连接恢复后，存储卷必须重新同步，然后才能恢复到正常的持续复制状态。重新同步过程确保两份数据副本恢复到一致状态。

动态环境下的容错能力

在中断事件中，实例或存储卷可用性问题是最常见的中断类型，通过执行简单的故障转移操作可以主要解决这些问题。这能通过可读的备用实例和卷恢复可用性。如果存储卷出现故障，会用新存储卷替换。这主要是出于持久性的原因，同时也有助于后续存储卷的重新同步性能提升。完成后，存储卷会被重新同步，复制将恢复。

在出现组件表现异常的情况下，实例或存储卷的替换也可能是一个选项。例如，显著或长期的延迟增加或带宽减少可能表明资源路径位置存在问题。在这种情况下，替换预计将是一个永久性解决方案。需注意，替换可能会影响性能，因此仅在必要时进行。

在某些情况下，整个 AWS 区域或可用区可能受到影响，例如在极端天气或大规模停电期间。此时，自动监控系统确保 Amazon RDS 实例的连续可用性，并采取谨慎的方法，避免中断，手动观察者则会采取必要的行动。观察者使用监控和可用性信息暂停不必要的自动恢复操作，直到根本问题解决。

总结

Amazon RDS MultiAZ DB 集群配置提升了客户数据的可用性和持久性。通过自动监控和问题检测，以及随后采取的纠正措施来恢复在中断事件中的可用性，MultiAZ DB 集群确保您的数据持久存在。有关更多信息，请查看 Amazon RDS 高可用性。

如有问题，请在 AWS rePost 提问或留下评论。

关于作者

Ankush Agarwal 在 AWS 担任解决方案架构师，专注于使用 AWS 开发高弹性工作负载。他在使用 AWS 服务创建、执行和增强数据分析工作负载方面有丰富经验。Ankush 在空闲时间喜欢探索城市森林和观看科幻电影。