发布于: Nov 30, 2022
【概要】数据丢了能恢复吗？答案是不一定的，比如覆盖全球的关键工作负载有严格的可用性要求，可能需要容忍整个区域的服务中断。对于此要求，过去需要在性能、可用性、成本和数据完整性之间做出痛苦的选择，有时需要开展大量的重新设计工作。
数据丢了能恢复吗？答案是不一定的，比如覆盖全球的关键工作负载有严格的可用性要求，可能需要容忍整个区域的服务中断。对于此要求，过去需要在性能、可用性、成本和数据完整性之间做出痛苦的选择，有时需要开展大量的重新设计工作。由于涉及的实施和基础设施成本高昂，一些企业不得不对其应用程序划分重要层级，只有最关键的应用程序才能得到良好的保护。
Amazon Aurora 全球数据库旨在切实满足客户和企业对全球分布式应用程序的要求。这可让 Amazon Aurora 覆盖多个 Amazon Web Services 区域并提供以下功能：
- 一种灾难恢复解决方案，可以应对完整的区域性故障并具有低恢复点目标 (RPO) 和低恢复时间目标 (RTO)，同时最大限度地减少对受保护数据库群集的性能影响
- 在辅助区域中使用只读副本进行快速本地读取，为接近这些区域的用户提供服务，而无需连接到主区域中的 Aurora 集群
- 通过在一分钟内提升辅助区域中的 Aurora 集群，实现从主区域到辅助区域的跨区域迁移
恢复时间目标 (RTO) 是指从服务中断到服务恢复的最大可接受延迟时间。该目标决定了可接受的服务不可用时间段。恢复点目标 (RPO) 是指自最近的数据恢复点以来可接受的最长间隔时间。该目标决定了在最近的恢复点和服务中断之间可以接受的数据丢失。例如，1 小时的 RPO 意味着灾难发生之后，您可能会丢失长达 1 小时的数据。
本博文介绍了如何使用涵盖多个区域的 Aurora 全球数据库，为兼容 PostgreSQL 的 Amazon Aurora 设置跨区域灾难恢复 (DR)。Aurora 全球数据库 使用基于全局存储的复制，其中新提升为主集群的集群可在一分钟内承载完整的读写工作负载，从而最大限度地减少对应用程序正常运行时间的影响。
Aurora 是一种旨在全面发挥云上联网、处理和存储资源丰富的优势的关系数据库。Aurora 在用户可见层面保持了与 MySQL 和 PostgreSQL 的兼容，同时又使用先进的特制分布式存储系统。有关 Aurora 特制分布式存储系统的详细信息，请参阅 Aurora 存储引擎简介。
使用一个区域中的主 Aurora 集群和另一个区域中的辅助 Aurora 集群创建 Aurora 全球数据库。Aurora 全球数据库 使用 Aurora 特制存储层中的专用基础设施来处理跨区域的复制。存储层中的专用复制服务器处理复制工作，即使是在系统高负载期间，您也能够在不影响数据库性能的情况下实现增强的恢复和可用性目标。Aurora 全球数据库 使用物理存储级的复制来创建具有相同数据集的主数据库副本，从而不再依赖逻辑复制过程。
下图显示了一个 Aurora 全球数据库，其中包含涵盖主区域和辅助区域的 Aurora 集群。
该过程包括以下步骤：
- Aurora 集群的主实例将日志记录并行发送到主区域中的存储节点、副本实例和复制服务器。
- 主区域中的复制服务器将日志记录流式传输到辅助区域中的复制代理。
- 复制代理将日志记录并行发送到辅助区域中的存储节点和副本实例。
- 主区域中的复制服务器从存储节点中提取日志记录，以便在服务中断后及时应用跟进。
Aurora 存储系统会自动在单个区域内的三个可用区中共维护六个数据副本，同时自动尝试在健康的可用区中恢复数据库，而不会丢失数据，这就显著提升了服务持久性和可用性。写入仲裁需要得到四个副本（共计六个副本）的确认，而读取仲裁则要得到受保护组中三个成员（共计六个成员）的确认。数据将持续实时的将 Aurora 备份到带有 Amazon Simple Storage Service (Amazon S3)，不会对最终用户产生性能影响。
下图显示了一个 Aurora 全球数据库，其中包含从主区域到多个辅助区域的物理存储级出站复制。
我们可以使用 Aurora 全球数据库，配置多达五个辅助区域以及每个辅助区域中最多 16 个只读副本。每个辅助集群必须位于与主集群和任何其他辅助集群不同的区域中。
使用 Aurora 全球数据库，您可以选择两种不同的故障转移途径：
- 托管的计划故障转移 – 要将主数据库集群重新定位到 Aurora 全球数据库中的一个辅助区域，请参阅使用 Amazon Aurora 全球数据库 的托管的计划故障转移。使用此功能时，RPO 的值为 0（无数据丢失），并且它会将辅助数据库集群与主数据库集群同步，然后再执行其他任何更改。此自动化过程的 RTO 通常低于手动故障转移的 RTO。
- 手动的计划外故障转移 – 要从计划外服务中断中恢复，您可以手动执行跨区域故障转移，将故障转移到 Aurora 全球数据库中的某个辅助区域。此手动过程的 RTO 取决于速度。RPO 通常以秒为单位进行测量，但这取决于发生故障时整个网络的 Aurora 存储复制延迟。
下图包含面向 Aurora PostgreSQL 的 Aurora 全球数据库，其中显示了两个主要组成部分：
- 连接到主区域中 Aurora 集群的应用程序，该应用程序从写入器实例执行读取和写入操作，并且仅从只读副本读取。
- 连接到辅助区域中 Aurora 集群的应用程序，这些应用程序只从只读副本执行读取。
创建 Amazon Route 53 友好 DNS 名称（CNAME 记录），以指向不断变化的不同 Aurora 读取器和写入器终端节点，从而最大限度地减少因故障转移和重新配置而重新链接应用程序所需的手动工作量。有关详细信息，请参阅使用域名开启与 Amazon RDS 数据库实例的连接。
对于主区域内整个区域的基础设施或服务不可用，从而导致数据库在计划外服务中断期间潜在降级或隔离的极少数情况，您可以在理解存在数据潜在丢失（由 RPO 衡量）的情况下通过将辅助集群提升为主集群来手动启动故障转移或者编写脚本执行故障转移
故障转移完成后，此提升的区域（旧的辅助区域）充当新的主 Aurora 集群，可以在一分钟内承载完整的读写工作负载，从而最大限度地减少对应用程序正常运行时间的影响。当旧的主区域的基础设施或服务可用时，通过添加区域操作可充当新的辅助 Aurora 集群，在计划外服务中断期间仅处理来自应用程序的读取工作负载。在撰写本文时，Aurora 全球数据库 不提供托管的计划外故障转移功能。
为了部署此解决方案，我们为兼容 PostgreSQL 的 Aurora 集群设置了 Aurora 全球数据库。您可以从 Amazon Web Services 管理控制台、Amazon Web Services 命令行界面（Amazon CLI）创建 Aurora 全球数据库，或者从 Amazon CLI 或开发工具包运行 CreateGlobalCluster 来创建 Aurora 全球数据库。