使用面向 Amazon Aurora PostgreSQL 的 Amazon Aurora 全球数据库 进行跨区域灾难恢复

覆盖全球的关键工作负载有严格的可用性要求，可能需要容忍整个区域的服务中断。对于此要求，过去需要在性能、可用性、成本和数据完整性之间做出痛苦的选择，有时需要开展大量的重新设计工作。由于涉及的实施和基础设施成本高昂，一些企业不得不对其应用程序划分重要层级，只有最关键的应用程序才能得到良好的保护。

Amazon Aurora 全球数据库 旨在切实满足客户和企业对全球分布式应用程序的要求。这可让 Amazon Aurora 覆盖多个 AWS 区域并提供以下功能：

• 一种灾难恢复解决方案，可以应对完整的区域性故障并具有低恢复点目标 (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 集群。

该过程包括以下步骤：

1. Aurora 集群的主实例将日志记录并行发送到主区域中的存储节点、副本实例和复制服务器。
2. 主区域中的复制服务器将日志记录流式传输到辅助区域中的复制代理。
3. 复制代理将日志记录并行发送到辅助区域中的存储节点和副本实例。
4. 主区域中的复制服务器从存储节点中提取日志记录，以便在服务中断后及时应用跟进。

Aurora 存储系统会自动在单个区域内的三个可用区中共维护六个数据副本，同时自动尝试在健康的可用区中恢复数据库，而不会丢失数据，这就显著提升了服务持久性和可用性。写入仲裁需要得到四个副本（共计六个副本）的确认，而读取仲裁则要得到受保护组中三个成员（共计六个成员）的确认。数据将持续实时的将Aurora备份到带有 Amazon Simple Storage Service (Amazon S3)，不会对最终用户产生性能影响。

下图显示了一个 Aurora 全球数据库，其中包含从主区域到多个辅助区域的物理存储级出站复制。

我们可以使用 Aurora 全球数据库，配置多达五个辅助区域以及每个辅助区域中最多 16 个只读副本。每个辅助集群必须位于与主集群和任何其他辅助集群不同的区域中。

使用 Aurora 全球数据库，您可以选择两种不同的故障转移途径：

• 托管的计划故障转移 – 要将主数据库集群重新定位到 Aurora 全球数据库中的一个辅助区域，请参阅使用 Amazon Aurora 全球数据库 的托管的计划故障转移。使用此功能时，RPO 的值为 0（无数据丢失），并且它会将辅助数据库集群与主数据库集群同步，然后再执行其他任何更改。此自动化过程的 RTO 通常低于手动故障转移的 RTO。
• 手动的计划外故障转移 – 要从计划外服务中断中恢复，您可以手动执行跨区域故障转移，将故障转移到 Aurora 全球数据库中的某个辅助区域。此手动过程的 RTO 取决于从计划外服务中断手动恢复 Aurora 全球数据库的速度。RPO 通常以秒为单位进行测量，但这取决于发生故障时整个网络的 Aurora 存储复制延迟。

下图包含面向 Aurora PostgreSQL 的 Aurora 全球数据库，其中显示了两个主要组成部分：*

• 连接到主区域中 Aurora 集群的应用程序，该应用程序从写入器实例执行读取和写入操作，并且仅从只读副本读取。
• 连接到辅助区域中 Aurora 集群的应用程序，这些应用程序只从只读副本执行读取。

创建 Amazon Route 53 友好 DNS 名称（CNAME 记录），以指向不断变化的不同 Aurora 读取器和写入器终端节点，从而最大限度地减少因故障转移和重新配置而重新链接应用程序所需的手动工作量。有关详细信息，请参阅使用域名开启与 Amazon RDS 数据库实例的连接。

对于主区域内整个区域的基础设施或服务不可用，从而导致数据库在计划外服务中断期间潜在降级或隔离的极少数情况，您可以在理解存在数据潜在丢失（由RPO衡量）的情况下通过将辅助集群提升为主集群来手动启动故障转移或者编写脚本执行故障转移

故障转移完成后，此提升的区域（旧的辅助区域）充当新的主 Aurora 集群，可以在一分钟内承载完整的读写工作负载，从而最大限度地减少对应用程序正常运行时间的影响。当旧的主区域的基础设施或服务可用时，通过添加区域操作可充当新的辅助 Aurora 集群，在计划外服务中断期间仅处理来自应用程序的读取工作负载。在撰写本文时，Aurora 全球数据库 不提供托管的计划外故障转移功能。

为了部署此解决方案，我们为兼容 PostgreSQL 的 Aurora 集群设置了 Aurora 全球数据库。您可以从 AWS 管理控制台、AWS 命令行界面 (AWS CLI) 创建 Aurora 全球数据库，或者从 AWS CLI 或开发工具包运行 CreateGlobalCluster 来创建 Aurora 全球数据库。

先决条件

在开始操作之前，请务必完成以下先决条件：

• 选择主要区域和辅助区域以部署 Aurora 全球数据库，服务应用程序并实现低延迟和灾难恢复。
• 确认面向 Aurora 的 Aurora 全球数据库 与 PostgreSQL 的兼容性 。在 10.14 版（及更高版本）、11.9 版（及更高版本）和 12.4 版（及更高版本）中提供此兼容性。
• 在主区域中创建一个读/写 Aurora PostgreSQL 数据库。要使用 AWS CloudFormation 模板创建 Aurora PostgreSQL 数据库，请参阅使用 AWS CloudFormation 以推荐的最佳实践部署 Amazon Aurora PostgreSQL 数据库集群。

为预先存在的 Aurora PostgreSQL 集群创建 Aurora 全球数据库

对于本博文，我们使用主区域中预先存在的 Aurora PostgreSQL 集群。要创建 Aurora 全球数据库，请完成以下步骤：

• 在 Amazon RDS 控制台上，选择数据库。
• 选择源集群。本博文选择 us-east-1 区域中的源集群。
• 在操作下拉菜单中，选择添加区域。

• 在添加区域页面，对于全球数据库标识符，请输入全球数据库的名称；例如，globalcluster。

这是包含写入器和读取器区域的全局集群的名称。

• 对于辅助区域，选择您的目标区域。本博文选择美国西部（俄勒冈）。

• 对于此页面上的其余设置，请使用与用于创建 Aurora 数据库集群相同的设置。

全局集群创建完成后，控制台上的视图类似于以下屏幕截图。

此时，写入器和读取器群集都处于在线状态，可以接受传入的流量。

监控面向 Aurora PostgreSQL 集群的 Aurora 全球数据库

要监控数据库，请完成以下步骤：

• 使用 psql 或 pgadmin 连接到写入器区域中的 Aurora 全球数据库主集群终端节点。
• 使用 aurora_global_db_status 函数查看全球数据库辅助数据库集群的延迟时间：
  • => select * from aurora_global_db_status();
  • aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
  • ————+———————+————————+—————–+—————————+—————-+—————
  • us-east-1  |           110115467 |                     -1 |              -1 | 1970-01-01 00:00:00+00    |              0 |             0
  • us-west-2  |           110115462 |                    483 |             483 | 2020-08-23 03:37:03.7+00  |              0 |         97552
  • (2 rows))

输出中的每一行包括全球数据库的一个数据库集群，其中包含以下列：

• aws_region – 此数据库集群所在的区域。对于按引擎列出区域的表，请参阅区域和可用区。
• highest_lsn_written – 当前在此数据库集群上写入的最高日志序列号 (LSN)。
• durability_lag_in_msec – 在辅助数据库集群上写入的最高 LSN (highest_lsn_written) 与主数据库集群上的highest_lsn_written 之间的时间戳之差。
• rpo_lag_in_msec –  恢复点目标 (RPO) 延迟。此滞后是存储在辅助数据库集群上的最新用户事务提交与存储在主数据库集群上的最新用户事务提交之间的时差。 last_lag_calculation_time – 最后为 replication_lag_in_msec 和 rpo_lag_in_msec 计算值时的时间戳。
• feedback_epoch – 辅助数据库集群生成热备用信息时使用的纪元。
• feedback_xmin – 辅助数据库集群使用的最小（最早）活跃事务 ID。
• 使用 aurora_global_db_instance_status 函数列出主数据库集群和辅助数据库集群的所有辅助数据库实例：
  • => select * from aurora_global_db_instance_status();
  • server_id    |              session_id              | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldes
  • t_read_view_lsn | visibility_lag_in_msec
  • —————-+————————————–+————+————-+——————+—————-+—————+——
  • —————-+————————
  • sourceinstance | MASTER_SESSION_ID                    | us-east-1  |   110118654 |                  |                |               |
  • |
  • targetinstance | abc79c10-c7f7-40e0-872c-3db40225aa90 | us-west-2 | 110118609 |        110118643 |              0 |         98064 |
  • 110118604 | 8  (2 rows)

输出中的每一行包括全球数据库的一个数据库实例，其中包含以下列：

• server_id – 数据库实例的服务器标识符
• session_id – 当前会话的唯一标识符
• aws_region – 此数据库实例所在的区域
• durable_lsn – 在存储中持久存在的 LSN
• highest_lsn_rcvd – 数据库实例从写入器数据库实例获得的最高 LSN
• feedback_epoch – 数据库实例生成热备用信息时使用的纪元
• feedback_xmin – 数据库实例使用的最小（最早）活跃事务 ID
• oldest_read_view_lsn – 数据库实例用于从存储中读取数据的最早 LSN
• visibility_lag_in_msec – 此数据库实例落后于写入器数据库实例的程度

Aurora 揭示了各种 Amazon CloudWatch 指标，您可以用来监控并确定兼容 PostgreSQL 的 Aurora 全球数据库的运行状况和性能。有关更多信息，请参阅使用 Amazon CloudWatch 监控 Amazon Aurora 指标。

• 在辅助区域中的 Amazon Relational Database Service (Amazon RDS) 控制台上，选择辅助数据库集群（本博文中选择了 targetcluster）。

在监控选项卡中，您可以更具体地查看以下与全局集群和辅助数据库集群相关的关键指标：

• • AuroraGlobalDBReplicatedWriteIO – 复制到辅助区域的写入 I/O 数
  • AuroraGlobalDBDataTransferBytes – 传输到辅助区域的重做日志量（以字节为单位）
  • AuroraGlobalDBReplicationLag – 辅助区域落后于主区域中写入器的时间量（以毫秒为单位）

以下屏幕截图显示了这些指标的控制台视图。

您可以使用 CloudWatch 控制台上的 CloudWatch 控制面板监控 Aurora 全球数据库的延迟、复制的 I/O 和跨区域复制数据传输。

使用 Aurora PostgreSQL 测试 Aurora 全球数据库的 DDL 和 DML

要测试全球数据库的 DDL 和 DML，请完成以下步骤：

• 连接到主区域中的全球数据库主 Aurora PostgreSQL 集群写入器终端节点（本博文中是 sourcecluster）。
• 创建示例表和数据，然后使用以下代码执行 DML 以测试跨区域的复制：
  • => CREATE TABLE categories (
  • (>     category_id smallint NOT NULL Primary Key,
  • (>     category_name character varying(15) NOT NULL,
  • (>     description text
  • (> );
  • CREATE TABLE
  • => INSERT INTO categories VALUES (1, ‘Condiments’, ‘Sweet and savory sauces, relishes, spreads, and seasonings’);
  • INSERT 0 1
  • => INSERT INTO categories VALUES (2, ‘Seafood’, ‘Seaweed and fish’);
  • INSERT 0 1
  • => select count(*) from categories;
  • count
  • ——-
  • 2
  • (1 row)
• 连接到辅助区域中的全球数据库辅助 Aurora PostgreSQL 集群写入器终端节点（本博文中是 targetcluster）。
• 使用以下代码查询数据：
  • => select count(*) from categories;
  • count
  • ——-
  • 2
  • (1 row)

使用 Aurora PostgreSQL 管理 Aurora 全球数据库的恢复

恢复点目标 (RPO) 是企业在发生灾难时可以容忍的丢失数据量（按时间衡量）。如果发生影响主数据库集群的网络或硬件故障等灾难，则可以使用托管 RPO 控制最大数据丢失量，因为在故障转移后，辅助区域中的辅助数据库集群落后于主数据库集群。这种数据丢失是按时间衡量的，称为 RPO 延迟时间。设置 RPO 之后，Aurora PostgreSQL 会按如下方式在您的全球数据库中强制执行此指标：

• 如果至少一个辅助数据库集群的 RPO 延迟时间小于 RPO 时间，则允许在主数据库集群上提交事务。
• 如果没有辅助数据库集群的 RPO 延迟时间小于 RPO 时间，则阻止事务提交。如果 Aurora PostgreSQL 开始阻止提交，它会在 PostgreSQL 日志文件中插入一个事件。然后，它会发出等待事件，其中显示已阻止的会话。
• 只要至少一个辅助数据库集群的 RPO 延迟时间小于 RPO 时间，就允许在主数据库集群上再次提交事务。

RPO 设置

一种较好的做法是使用具有相同设置的 Aurora 全球数据库的主集群和辅助集群 Aurora 参数组。这样，在主区域出现故障的情况下，辅助区域中新主集群的配置与旧的主集群具有相同的配置。

• 在 Amazon RDS 控制台上，标识全球数据库的主数据库集群参数组。
• 打开主数据库集群参数组并设置 global_db_rpo 参数。
• 有关说明，请参阅修改数据库集群参数组中的参数。
• 设置 global_db_rpo 参数值为恢复点目标所需的秒数。

有效值从 20 秒开始。

这种方法可确保 Aurora PostgreSQL 不允许导致违反所选 RPO 时间的事务提交任务完成。

面向 Aurora PostgreSQL 的 Aurora 全球数据库的故障转移

您的 Aurora 全球数据库可能包含多个辅助区域，如果服务中断影响了主区域，您可以选择要故障转移到哪个区域。监控所有辅助区域的复制延迟，以确定要选择哪个辅助区域。选择复制延迟时间最小的辅助群集意味着数据丢失最少。

如果一个区域中的整个集群变得不可用，则可以将全球数据库中的另一个辅助 Aurora PostgreSQL 集群提升为具有读写功能。如果另一个辅助区域中的集群更适合作为主集群，则您可以手动激活故障转移机制。

提升辅助 Aurora PostgreSQL 集群

要将辅助区域中的辅助 Aurora PostgreSQL 集群提升为独立的数据库集群，请完成以下步骤：

• 在 Amazon RDS 控制台上，定位到辅助区域中辅助数据库集群的 Aurora PostgreSQL 集群详细信息页面。
• 选择辅助数据库集群（本博文中是 targetcluster)。
• 在操作菜单中，选择从全局删除。

• 系统将显示一条消息，确认这将中断从主数据库集群进行的复制。
• 选择删除并提升。

在本博文中，将 us-west-2 中的 targetcluster 提升为独立集群。

提升过程所用时间应少于 1 分钟。完成后，您应该看到旧的辅助数据库集群的数据库实例现在是写入器节点。

您的应用程序写入工作负载现在应该指向新提升的 Aurora PostgreSQL 集群 targetcluster 的集群写入器终端节点。

小结

本博文介绍了如何使用 Aurora 全球数据库为兼容 PostgreSQL 的 Aurora 集群实施跨区域灾难恢复。这可让您创建全局分布式应用程序，维持具有最小 RPO 和 RTO 的灾难恢复解决方案来应对整个区域的故障，并且可以为全球各地区域提供低延迟读取。现在就开始使用 Amazon Aurora 全球数据库！ 我们欢迎您提供反馈。请在评论中分享您的经验和任何问题。

本篇作者