灾难恢复和 Amazon Aurora 全局数据库 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

灾难恢复和 Amazon Aurora 全局数据库

Aurora 全局数据库提供的故障转移功能比默认 Aurora 数据库集群提供的故障转移功能更全面。使用 Aurora 全局数据库,您可以对灾难进行规划并很快地从灾难中恢复。灾难恢复通常以 RTO 和 RPO 的值来衡量。

  • 恢复时间目标 (RTO) – 灾难后系统恢复工作状态所需的时间。换言之,RTO 用于衡量停机时间。对于 Aurora 全球数据库,RTO 大约为数分钟。

  • 恢复点目标 (RPO) – 可能丢失的数据量(按时间衡量)。对于 Aurora 全球数据库,RPO 通常以秒为单位进行测量。通过基于 Aurora PostgreSQL 的全局数据库,您可以使用 rds.global_db_rpo 参数设置和跟踪 RPO 上限,但这样做可能会影响主集群写入器节点上的事务处理。有关更多信息,请参阅 管理基于 Aurora PostgreSQL 的全局数据库的 RPO

通过 Aurora 全局数据库,您可以从两种不同的故障转移方法中进行选择。

  • 托管的计划内故障转移 – 此功能适用于受控环境,例如灾难恢复 (DR) 测试场景、操作维护和其他计划内的操作程序。托管的计划内故障转移允许您将 Aurora 全局数据库的主数据库集群重新定位到其中一个辅助区域。由于此功能会在进行任何其他更改之前将辅助数据库集群与主数据库集群同步,因此 RPO 为 0(不会造成数据丢失)。此自动过程的 RTO 通常低于“分离并提升”故障转移过程的 RTO,因为系统将为您处理降级、提升和所有同步操作。要了解更多信息,请参阅“Amazon Aurora 全局数据库的托管计划内故障转移”。

  • 计划外故障转移(“分离并提升”)– 要从计划外停机中恢复,您可以执行跨区域故障转移到 Aurora 全局数据库中的一个辅助区域。此手动过程的 RTO 取决于您执行 从计划外停机中恢复 Amazon Aurora 全局数据库 中列出的任务的速度。RPO 通常以秒为单位进行测量,但这取决于发生故障时整个网络的 Aurora 存储复制滞后时间。

Amazon Aurora 全局数据库的托管计划内故障转移

通过使用托管的计划内故障转移,您可以定期将 Aurora 全局数据库的主集群重新定位到其他 Amazon 区域。对于政府机构、金融机构和许多其他受监管行业来说,法律规定其应该能够在生产系统中展示此项功能。此功能适用于受控环境,例如灾难恢复 (DR) 测试场景、操作维护和其他计划内的操作程序。

例如,假设有一家总部位于纽约的金融机构在旧金山、英国和欧洲设有分支机构。该组织的核心业务应用程序使用 Aurora 全局数据库。其主集群在 美国东部(俄亥俄)区域 中运行,而辅助集群在 美国西部(加利福利亚北部)区域、欧洲(伦敦)区域 和 欧洲(法兰克福)区域 中运行。每季度,它都会将主集群从(当前)主 Amazon 区域重新定位到为指定轮换的辅助区域。

并非每个组织都需要定期轮换其 Aurora 全局数据库的主集群。但是,在监管机构审计期间,能够执行此操作是满足灾难恢复需求的关键要求。对于所有类型的组织,我们均建议将托管的计划内故障转移作为灾难恢复准备的最佳实践。这不仅可以确保您的程序完整和准确,更重要的是,员工必须在灾难恢复故障转移真正发生之前接受培训以执行灾难恢复故障转移。

注意

托管的计划内故障转移适用于运行正常的 Aurora 全局数据库。要从计划外停机中恢复,请按照 从计划外停机中恢复 Amazon Aurora 全局数据库 中详细介绍的“分离并提升”过程进行操作。

在托管的计划内故障转移期间,主集群会将故障转移到您选择的辅助区域,同时维护 Aurora 全局数据库的现有复制拓扑。在托管的计划内故障转移过程开始之前,Aurora 全局数据库会将所有辅助集群与其主集群同步。确保所有集群都同步后,托管的故障转移才会开始。主区域中的数据库集群变为只读状态。所选的辅助集群将其一个只读节点提升为完全写入器状态,从而允许该集群担任主集群的角色。由于所有辅助集群在过程开始时都与主集群同步,因此新的主集群将继续执行 Aurora 全局数据库的操作,而不会丢失任何数据。您的应用程序在短时间内不可用,因为主集群和所选的辅助集群将担任其新角色。

为了优化应用程序可用性,我们建议您在使用此功能之前执行以下操作:

  • 在非高峰时间段,或在向主数据库集群写入操作最少的其他时间执行此操作。

  • 使应用程序离线以防止写入内容被发送到 Aurora 全局数据库的主集群。

  • 检查 Aurora 全局数据库中所有辅助 Aurora 数据库集群的滞后时间。选择托管的计划内故障转移总体滞后时间的最短时间。使用 Amazon CloudWatch 查看所有辅助数据库集群的 AuroraGlobalDBReplicationLag 指标。此指标会指出辅助数据库集群滞后于主数据库集群的时间(以毫秒为单位)。该值与 Aurora 完成故障转移所需的时间成正比。换言之,滞后值越大,停机时间越长,因此请选择滞后值最小的区域。

    有关 Aurora 的 CloudWatch 指标的更多信息,请参阅 Amazon Aurora 的集群级指标

在托管的计划内故障转移期间,所选的辅助数据库集群将提升为新角色,即主数据库集群。但是,它不会继承主数据库集群的各种配置选项。配置不匹配可能会导致性能问题、工作负载不兼容和其他异常行为。为避免出现此类问题,我们建议您解决以下方面 Aurora 全局数据库集群之间的差异问题:

  • 为新的主数据库集群配置 Aurora 数据库集群参数组(如有必要)– 您可以为 Aurora 全局数据库中的每个 Aurora 集群单独配置 Aurora 数据库集群参数组。这意味着,当您提升辅助数据库集群以接管主数据库集群的角色时,辅助数据库集群中参数组的配置可能与主数据库集群的配置不同。如果是这样,请修改提升后的辅助数据库集群的参数组,使其与主集群的设置一致。要了解如何操作,请参阅修改 Aurora 全局数据库的参数

  • 配置监控工具和选项(例如 Amazon CloudWatch Events 和警报)– 根据全局数据库的需要,为提升后的数据库集群配置相同的日志记录能力、警报等等。与参数组一样,在故障转移过程中,这些功能的配置不会从主数据库集群继承。有关 Aurora 数据库集群和监控的更多信息,请参阅 Amazon Aurora 监控概览

  • 配置与其他 Amazon 服务的集成 – 如果您的 Aurora 全局数据库与 Amazon 服务(例如 Amazon Secrets Manager、Amazon Identity and Access Management、Amazon S3 和 Amazon Lambda)集成,则需要确保根据需要对这些服务进行配置。有关将 Aurora 全局数据库与 IAM、Amazon S3 和 Lambda 集成的更多信息,请参阅 将 Amazon Aurora 全局数据库与其他 Amazon 服务结合使用。要了解有关 Secrets Manager 的更多信息,请参阅如何跨 Amazon 区域自动复制 Amazon Secrets Manager 中的密钥

故障转移过程完成后,提升后的 Aurora 数据库集群即可处理 Aurora 全局数据库的写入操作。您可以更改应用程序的终端节点以使用新的终端节点。如果您在创建 Aurora 全局数据库时接受了提供的名称,则可以在应用程序中从提升集群的终端节点字符串中删除 -ro 以更改终端节点。

例如,辅助集群的终端节点 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 将在该集群提升为主集群时变为终端节点 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com

您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 对 Aurora 全局数据库进行故障转移。

在 Aurora 全局数据库上启动故障转移过程

  1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 选择 Databases(数据库),然后找到要进行故障转移的 Aurora 全局数据库。

  3. 从操作菜单中选择 Fail over global database(全局数据库故障转移)。当您在下一步中选择故障转移目标后,故障转移过程才会开始。此时,故障转移处于待处理状态。

    
                 启动 Aurora 全局数据库的故障转移过程
    1. 选择要提升为主数据库集群的辅助 Aurora 数据库集群。辅助数据库集群必须为 available(可用)状态。如果您有多个辅助数据库集群,则可以比较所有辅助数据库集群的滞后量,然后选择滞后最少的一个。

      
                 选择要提升的辅助数据库集群
    2. 选择 Fail over global database(全局数据库故障转移)以确认您选择的辅助数据库集群并开始故障转移过程。

      提示

      故障转移过程可能需要一段时间才能完成。在过程进行中,您可以取消该过程,但可能需要一段时间才能使 Aurora 全局数据库恢复到原始配置。

      
                 故障转移过程的辅助集群选择器和确认卡

      数据库列表的 Status(状态)列显示了故障转移过程中每个 Aurora 数据库实例和 Aurora 数据库集群的状态。

      
                 正在进行的故障转移。状态列显示过程的状态。

      控制台顶部的状态栏将显示进度并提供 Cancel failover(取消故障转移)选项。如果选择 Cancel failover(取消故障转移),系统会提示您选择继续进行故障转移或取消故障转移过程。

      
                 取消故障转移警报

      如果要取消故障转移,请选择 Cancel failover(取消故障转移)。

    3. 如果选择 Close(关闭)则会继续进行故障转移并取消提示。

故障转移完成后,您可以在 Databases(数据库)列表中看到 Aurora 数据库集群及其当前状态,如下所示。


             正在进行的故障转移。状态列显示过程的状态。

对 Aurora 全局数据库进行故障转移

使用 failover-global-cluster CLI 命令对 Aurora 全局数据库进行故障转移。使用命令,传递下列参数的值。

  • --region – 指定 Aurora 全局数据库的主数据库集群运行的 Amazon 区域。

  • --global-cluster-identifier – 指定 Aurora 全局数据库的名称。

  • --target-db-cluster-identfier – 指定要提升为 Aurora 全局数据库的主数据库集群的 Aurora 数据库集群的 Amazon 资源名称 (ARN)。

对于 Linux、macOS 或 Unix:

aws rds --region aws-Region \ failover-global-cluster --global-cluster-identifier global_database_id \ --target-db-cluster-identifier ARN-of-secondary-to-promote

对于 Windows:

aws rds --region aws-Region ^ failover-global-cluster --global-cluster-identifier global_database_id ^ --target-db-cluster-identifier ARN-of-secondary-to-promote

要对 Aurora 全局数据库进行故障转移,请运行 FailoverGlobalCluster API 操作。

管理基于 Aurora PostgreSQL 的全局数据库的 RPO

通过基于 Aurora PostgreSQL 的全局数据库,您可以使用 PostgreSQL 的 rds.global_db_rpo 参数管理 Aurora 全局数据库的恢复点目标 (RPO)。RPO 表示在停机时可能丢失的最大数据量。

为基于 Aurora PostgreSQL 的全局数据库设置 RPO 后,Aurora 会监控所有辅助集群的 RPO 滞后时间,以确保至少有一个辅助集群保留在目标 RPO 窗口内。RPO 滞后时间是另一个基于时间的指标。

故障转移后,数据库在新的 Amazon 区域中恢复操作时会使用 RPO。Aurora 会按如下方式评估 RPO 和 RPO 滞后时间,以便在主数据库集群上提交(或阻止)事务:

  • 如果至少有一个辅助数据库集群的 RPO 滞后时间小于 RPO,则提交事务。

  • 如果所有辅助数据库集群的 RPO 滞后时间大于 RPO,则阻止事务。它还会将事件记录到 PostgreSQL 日志文件中,并发出显示被阻止的会话的“等待”事件。

换言之,如果所有辅助集群都落后于目标 RPO,则 Aurora 会在主集群中暂停,直到至少一个辅助集群与目标 RPO 同步。一旦至少一个辅助数据库集群的滞后时间小于 RPO,就会重新提交事务。结果是在满足 RPO 条件之后,才能提交事务。

如果按下述设置此参数,则还可以监控其生成的指标。您可以通过使用 psql 或其他工具查询 Aurora 全局数据库的主数据库集群并获取基于 Aurora PostgreSQL 的全局数据库操作的详细信息来执行此操作。要了解如何操作,请参阅监控基于 Aurora PostgreSQL 的 Aurora 全局数据库

设置恢复点目标

rds.global_db_rpo 参数控制 PostgreSQL 数据库的 RPO 设置。Aurora PostgreSQL 支持此参数。rds.global_db_rpo 的有效值的范围是从 20 秒到 2147483647 秒(68 年)。请选择符合您的业务需求和使用案例的真实值。例如,您可能希望最多为 RPO 留出 10 分钟的时间,在这种情况下,可以将值设置为 600。

您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 为基于 Aurora PostgreSQL 的全局数据库设置此值。

设置 RPO

  1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 选择 Aurora 全局数据库的主集群,然后打开 Configuration(配置)选项卡以查找其数据库集群参数组。例如,运行 Aurora PostgreSQL 11.7 的主数据库集群的默认参数组为 default.aurora-postgresql11

    参数组无法直接编辑。您可以改而执行以下操作:

    • 使用适当的默认参数组作为起点创建自定义数据库集群参数组。例如,基于 default.aurora-postgresql11 创建自定义数据库集群参数组。

    • 在自定义数据库参数组中,设置 rds.global_db_rpo 参数的值以符合您的使用案例。有效值的范围是从 20 秒到最大整数值 2147483647(68 年)。

    • 请将修改后的数据库集群参数组应用于 Aurora 数据库集群。

有关更多信息,请参阅 修改数据库集群参数组中的参数

要设置 rds.global_db_rpo 参数,请使用 modify-db-cluster-parameter-group CLI 命令。在此命令中,请指定主集群参数组的名称和 RPO 参数的值。

以下示例将名为 my_custom_global_parameter_group 的主数据库集群参数组的 RPO 设置为 600 秒(10 分钟)。

对于 Linux、macOS 或 Unix:

aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

对于 Windows:

aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

要修改 rds.global_db_rpo 参数,请使用 Amazon RDS ModifyDBClusterParameterGroup API 操作。

查看恢复点目标

全局数据库的恢复点目标 (RPO) 存储每个数据库集群的 rds.global_db_rpo 参数中。您可以连接到要查看的辅助集群的终端节点,并使用 psql 查询该值的实例。

db-name=>show rds.global_db_rpo;

如果未设置此参数,查询将返回以下内容:

rds.global_db_rpo ------------------- -1 (1 row)

下一个响应来自 RPO 设置为 1 分钟的辅助数据库集群。

rds.global_db_rpo ------------------- 60 (1 row)

您还可以使用 CLI 获取集群的所有 user 参数的值,以便了解 rds.global_db_rpo 是否在任何 Aurora 数据库集群上处于活动状态。

对于 Linux、macOS 或 Unix:

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name lab-test-apg-global \ --source user

对于 Windows:

aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name lab-test-apg-global * --source user

该命令会对所有 user 参数(非 default-enginesystem 数据库集群参数)返回与以下内容类似的输出。

{ "Parameters": [ { "ParameterName": "rds.global_db_rpo", "ParameterValue": "60", "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.", "Source": "user", "ApplyType": "dynamic", "DataType": "integer", "AllowedValues": "20-2147483647", "IsModifiable": true, "ApplyMethod": "immediate", "SupportedEngineModes": [ "provisioned" ] } ] }

要了解有关查看集群参数组的参数的更多信息,请参阅 查看数据库集群参数组的参数值

禁用恢复点目标

要禁用 RPO,请重置 rds.global_db_rpo 参数。您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 重置参数。

禁用 RPO

  1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 在导航窗格中,选择参数组

  3. 在列表中,选择您的主数据库集群参数组。

  4. 选择编辑参数

  5. 选择 rds.global_db_rpo 参数旁边的框。

  6. 选择 Reset (重置)

  7. 当屏幕显示 Reset parameters in DB parameter group (重置数据库参数组中的参数) 时,选择 Reset parameters (重置参数)

有关如何使用控制台重置参数的更多信息,请参阅修改数据库集群参数组中的参数

要重置 rds.global_db_rpo 参数,请使用 reset-db-cluster-parameter-group 命令。

对于 Linux、macOS 或 Unix:

aws rds reset-db-cluster-parameter-group \ --db-cluster-parameter-group-name global_db_cluster_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

对于 Windows:

aws rds reset-db-cluster-parameter-group ^ --db-cluster-parameter-group-name global_db_cluster_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

要重置 rds.global_db_rpo 参数,请使用 Amazon RDS API ResetDBClusterParameterGroup 操作。

从计划外停机中恢复 Amazon Aurora 全局数据库

在极少数情况下,您的 Aurora 全局数据库可能会在其主 Amazon 区域中发生意外停机。如果发生这种情况,主 Aurora 数据库集群及其写入器节点将不可用,主集群和辅助集群之间的复制过程将停止。为了最大限度地减少停机时间 (RTO) 和数据损失 (RPO),您可以快速执行跨区域故障转移并重建 Aurora 全局数据库。

提示

我们建议您在实施此过程之前先了解此过程。准备好计划,以便在区域级问题初见端倪时快速处理。准备好在最短的滞后时间内识别辅助区域。定期使用 Amazon CloudWatch 来跟踪辅助集群的滞后时间。

在主区域发生计划外停机后将故障转移到辅助集群

  1. 停止向停机的 Amazon 区域中的主 Aurora 数据库集群发出 DML 语句和其他写入操作。

  2. 从辅助 Amazon 区域中标识作为新的主数据库集群的 Aurora 数据库集群。如果您的 Aurora 全局数据库中有两个(或更多)辅助 Amazon 区域,请选择滞后时间最短的辅助集群。

  3. 从 Aurora 全局数据库分离您所选的辅助数据库集群。

    从 Aurora 全局数据库删除辅助数据库集群会立即停止从主数据库集群到该辅助数据库集群的复制过程,并会将其提升为拥有完全读/写功能的独立预置的 Aurora 数据库集群。与该停机区域中的主集群关联的任何其他辅助 Aurora 数据库集群仍然可用,并且可以接受应用程序的调用。它们还会消耗资源。由于您要重新创建 Aurora 全局数据库,为避免分裂大脑和其他问题,请先删除其他辅助数据库集群,再在后续步骤中创建新的 Aurora 全局数据库。

    有关分离的详细步骤,请参阅 从 Amazon Aurora 全局数据库删除集群

  4. 重新配置应用程序,使用新的终端节点将所有写入操作发送到现在的独立 Aurora 数据库集群。如果您在创建 Aurora 全局数据库时接受了提供的名称,则可以在应用程序中从集群的终端节点字符串中删除 -ro 以更改终端节点。

    例如,辅助集群的终端节点 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 将在该集群从 Aurora 全局数据库分离时变为终端节点 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com

    在下一步中,当您开始向 Aurora 数据库集群添加区域时,该数据库集群将成为新的 Aurora 全局数据库的主集群。

  5. 向数据库集群添加 Amazon 区域。执行此操作后,从主数据库集群到辅助数据库集群的复制过程将会开始。有关添加区域的详细步骤,请参阅 将 Amazon 区域添加到 Amazon Aurora 全局数据库

  6. 根据需要添加更多 Amazon 区域,以重新创建为了支持应用程序所需的拓扑。

确保在做出这些更改之前、更改期间和更改之后,将应用程序写入内容发送到正确的 Aurora 数据库集群,以避免 Aurora 全局数据库中数据库集群之间的数据不一致(大脑分裂问题)。

如果您为响应 Amazon 区域中的停机而进行上述重新配置,则可以通过托管的计划内故障转移过程,在解决停机问题后将 Aurora 全局数据库恢复到原始主 Amazon 区域。您的 Aurora 全局数据库必须使用 Aurora PostgreSQL 或 Aurora MySQL 支持托管的计划内故障转移功能的版本。有关更多信息,请参阅 Amazon Aurora 全局数据库的托管计划内故障转移