如何使用 Aurora 全球数据库为兼容 PostgreSQL 的 Aurora 集群实施跨区域数据灾难恢复

发布于: Aug 22, 2022

在过去我们经常需要容忍因区域间的服务中断而导致的数据丢失，现在我们可以利用 Aurora 全球数据库，实现跨区域的数据灾难恢复，接下来我们一起来看看具体如何操作吧！

先决条件

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

  • 选择主要区域和辅助区域以部署 Aurora 全球数据库，服务应用程序并实现低延迟和灾难恢复。
  • 确认面向 Aurora 的 Aurora 全球数据库 与 PostgreSQL 的兼容性 。在 10.14 版（及更高版本）、11.9 版（及更高版本）和 12.4 版（及更高版本）中提供此兼容性。
  • 在主区域中创建一个读/写 Aurora PostgreSQL 数据库。要使用 Amazon Web Services CloudFormation 模板创建 Aurora PostgreSQL 数据库，请参阅使用 Amazon Web Services 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 函数查看全球数据库辅助数据库集群的延迟时间：
o => select * from aurora_global_db_status();
o aws_region | highest_lsn_written | durability_lag_in_msec |rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch |   feedback_xmin
o ————+———————+————————+—————–+—————————+—————-+—————
o us-east-1 | 110115467 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
o us-west-2 | 110115462 | 483 | 483 | 2020-08-23 03:37:03.7+00 | 0 | 97552
o (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 函数列出主数据库集群和辅助数据库集群的所有辅助数据库实例：
o => select * from aurora_global_db_instance_status();
o server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldes
o t_read_view_lsn | visibility_lag_in_msec
o —————-+————————————–+————+————-+——————+—————-+—————+——
o —————-+————————
o sourceinstance | MASTER_SESSION_ID | us-east-1 | 110118654 | | | |
o |
o targetinstance | abc79c10-c7f7-40e0-872c-3db40225aa90 | us-west-2 | 110118609 | 110118643 | 0 | 98064 |
o 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 以测试跨区域的复制：
    o => CREATE TABLE categories (
    o (> category_id smallint NOT NULL Primary Key,
    o (> category_name character varying(15) NOT NULL,
    o (> description text
    o (> );
    o CREATE TABLE
    o
    o => INSERT INTO categories VALUES (1, ‘Condiments’, ‘Sweet and savory sauces, relishes, spreads, and seasonings’);
    o INSERT 0 1
    o => INSERT INTO categories VALUES (2, ‘Seafood’, ‘Seaweed and fish’);
    o INSERT 0 1
    o => select count(*) from categories;
    o count
    o ——-
    o 2
    o (1 row)

  • 连接到辅助区域中的全球数据库辅助 Aurora PostgreSQL 集群写入器终端节点（本博文中是 targetcluster）。
  • 使用以下代码查询数据：
    o => select count(*) from categories;
    o count
    o ——-
    o 2
    o (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 全球数据库！我们欢迎您提供反馈。请在评论中分享您的经验和任何问题。

相关文章

云财务管理开启企业管理新格局