在 Amazon Aurora Global Database 中使用切换或失效转移

与 Aurora 数据库集群在单个 Amazon Web Services 区域中提供的标准高可用性相比，Aurora Global Database 特征提供了更高的业务连续性和灾难恢复（BCDR）保护。通过使用 Aurora Global Database，您可以计划从罕见、计划外的区域性灾难或完全的服务级别中断中更快地恢复。

您可以参阅以下指南和程序，使用 Aurora Global Database 特征来计划、测试和实施 BCDR 策略。

计划业务连续性和灾难恢复

要计划业务连续性和灾难恢复策略，了解以下行业术语以及这些术语与 Aurora Global Database 特征的关系会很有帮助。

从灾难中恢复通常由以下两个业务目标驱动：

使用 Aurora Global Database 执行切换或失效转移时，需要将辅助数据库集群提升为主数据库集群。“区域性停机”一词通常用于描述各种故障情况。最坏的情况可能是影响数百平方英里的灾难性事件造成的广泛停电。但是，大多数停机的局部程度会高得多，仅影响一小部分云服务或客户系统。考虑停机的全部范围，以确保跨区域失效转移是正确的解决方案，并针对这种情况选择适当的失效转移方法。应使用失效转移还是切换方法取决于具体的停机情况：

对 Amazon Aurora Global Database 执行切换

通过使用切换，您可以定期更改主集群的区域。此方法适用于受控场景，例如操作维护和其他计划内操作过程。

切换有三种常见使用案例。

在切换期间，Aurora 会使您选择的辅助区域中的集群成为主集群。切换机制维护全局数据库的现有复制拓扑：它在相同区域中仍有相同数量的 Aurora 集群。在 Aurora 开始切换过程之前，它会等待所有辅助区域集群与主区域集群完全同步。然后，主区域中的数据库集群变为只读状态。所选的辅助集群将其一个只读节点提升为完全写入器状态，从而允许该辅助集群代入主集群的角色。由于所有辅助集群在过程开始时都与主集群同步，因此新的主集群将继续执行 Aurora 全局数据库的操作，而不会丢失任何数据。您的数据库在短时间内不可用，而主集群和所选的辅助集群将担任其新角色。

为了优化应用程序可用性，我们建议您在使用此特征之前执行以下操作：

如果使用的是 Aurora Global Database 写入器端点，则无需更改应用程序中的连接设置。验证 DNS 更改已传播，并且您可以连接新的主集群并对其执行写入操作。然后，您可以恢复应用程序的完整运行。

假设您的应用程序连接使用旧主集群的集群端点，而不是全局写入器端点。在这种情况下，请务必更改应用程序连接设置，以使用新主集群的集群端点。如果您在创建 Aurora 全局数据库时接受了提供的名称，则可以在应用程序中从提升集群的终端节点字符串中删除 -ro 以更改终端节点。例如，辅助集群的终端节点 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 将在该集群提升为主集群时变为终端节点 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com。

如果您使用的是 RDS 代理，请确保将应用程序的写入操作重定向到与新主集群关联的代理的相应读/写端点。此代理端点可能是默认端点或自定义读/写端点。有关更多信息，请参阅RDS 代理端点如何与全局数据库配合使用。

您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 对 Aurora Global Database 进行切换。

对您的 Aurora 全球数据库执行切换

1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/。

2. 选择数据库，然后找到要进行切换的 Aurora 全局数据库。

3. 从操作菜单中选择切换或失效转移全球数据库。

   

4. 选择切换。

   

5. 对于新的主集群，选择其中一个辅助 Amazon Web Services 区域中的活动集群作为新的主集群。

6. 选择确认。

切换完成后，您可以在数据库列表中看到 Aurora 数据库集群及其当前角色，如下图所示。

对您的 Aurora 全球数据库执行切换

使用 switchover-global-cluster CLI 命令对 Aurora Global Database 进行切换。使用命令，传递下列参数的值。

• --region - 指定 Aurora Global Database 的主数据库集群运行的 Amazon Web Services 区域。

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

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

对于 Linux、macOS 或 Unix：

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

对于 Windows：

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

要对 Aurora Global Database 进行切换，请运行 SwitchoverGlobalCluster API 操作。

从计划外停机中恢复 Amazon Aurora Global Database

在极少数情况下，您的 Aurora Global Database 可能会在其主 Amazon Web Services 区域中发生意外停机。如果发生这种情况，主 Aurora 数据库集群及其写入器节点将不可用，并且主数据库集群和辅助数据库集群之间的复制将停止。为了最大限度地减少停机时间（RTO）和数据丢失（RPO），您可以快速执行跨区域失效转移。

Aurora Global Database 有两种失效转移方法可供您在灾难恢复情况下使用：

执行 Aurora 全球数据库的托管式失效转移

这种方法用于在发生真实的区域性灾难或完全的服务级别中断时实现业务连续性。

在托管式失效转移期间，所选的辅助区域中的辅助集群将成为新的主集群。所选的辅助集群将其一个只读节点提升为完全写入器状态。此步骤允许集群代入主集群的角色。在此集群代入其新角色期间，您的数据库在短时间内不可用。一旦该旧主区域正常运行并再次可用，Aurora 就会自动将其作为辅助区域重新添加到全局集群中。因此，Aurora Global Database 的现有复制拓扑保持不变。

托管式失效转移不会等待所选辅助区域和当前主区域之间的数据同步。由于 Aurora Global Database 以异步方式复制数据，因此在所选的辅助 Amazon 区域升级为接受完整读/写功能之前，可能并非所有事务都复制到该区域。

为确保数据处于一致状态，Aurora 会在旧的主区域恢复后为其创建一个新的存储卷。在 Amazon 区域中创建新的存储卷之前，Aurora 会尝试在出现故障时拍摄旧存储卷的快照。这样，您就可以还原快照并从中恢复任何丢失的数据。如果此操作成功，Aurora 会将这个名为 rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp 的快照放在 Amazon Web Services Management Console的“快照”部分中。您也可以使用 describe-db-cluster-snapshots Amazon CLI 命令或 DescribeDBClusterSnapshots API 操作来查看该快照的详细信息。

当您启动托管式失效转移时，Aurora 还会尝试停止流经高可用 Aurora 存储层的写入流量。我们将这种机制称为“写入屏蔽”。如果该过程成功，Aurora 会触发一个 RDS 事件，告知您写入已停止。在极少数情况下，如果某个区域有多个可用区出现故障，则写入屏蔽过程可能无法及时成功。在这种情况下，Aurora 会触发一个 RDS 事件，通知您停止写入的过程已超时。如果可在网络上访问旧的主集群，Aurora 会在那里记录这些事件。否则，Aurora 会将事件记录在新的主集群上。要了解有关这些事件的更多信息，请参阅数据库集群事件。由于屏蔽写入是一种尽力而为的尝试，因此旧的主区域可能会暂时接受写入，从而导致脑裂问题。

建议您在对 Aurora Global Database 执行失效转移之前，先完成以下任务。这样做可以更大限度地降低脑裂问题的可能性，或从旧主集群的快照中恢复未复制数据的可能性。

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

通常，所选的辅助集群会在几分钟内代入主角色。一旦新的主区域的写入器数据库实例可用，您就可以将应用程序连接到该实例并恢复工作负载。Aurora 提升新的主集群后，它会自动重建所有其他辅助区域集群。

由于 Aurora 全球数据库使用异步复制，因此每个辅助区域的复制滞后可能会有所不同。Aurora 重建这些辅助区域，使其具有与新的主区域集群完全相同的时间点数据。完成重建任务的持续时间可能需要几分钟到几小时，具体取决于存储卷的大小和区域之间的距离。当辅助区域集群从新的主区域完成重建后，它们就可供进行读取访问了。

一旦新的主写入器已提升并可用，新的主区域的集群就可以处理 Aurora 全球数据库的读取和写入操作。

如果使用的是全局端点，则无需更改应用程序中的连接设置。验证 DNS 更改已传播，并且您可以连接新的主集群并对其执行写入操作。然后，您可以恢复应用程序的完整运行。

如果不使用全局端点，请务必更改应用程序的端点，以使用新提升的主数据库集群的集群端点。如果您在创建 Aurora 全局数据库时接受了提供的名称，则可以在应用程序中从提升集群的终端节点字符串中删除 -ro 以更改终端节点。

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

如果您使用的是 RDS 代理，请确保将应用程序的写入操作重定向到与新的主集群关联的代理的相应读取/写入端点。此代理端点可能是默认端点或自定义读/写端点。有关更多信息，请参阅RDS 代理端点如何与全局数据库配合使用。

为了还原全球数据库集群的原始拓扑，Aurora 会监控旧主区域的可用性。一旦该区域正常运行并再次可用，Aurora 就会自动将其作为辅助区域重新添加到全球集群中。在旧的主区域中创建新的存储卷之前，Aurora 会尝试在出现故障时拍摄旧存储卷的快照。它这样做是为了让您可以用它来恢复任何丢失的数据。如果此操作成功，Aurora 将创建一个名为 rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp 的快照。您可以在 Amazon Web Services Management Console的快照部分中找到该快照。还可以在 DescribeDBClusterSnapshots API 操作返回的信息中看到列出的此快照。

还原原始拓扑后，您可以通过在对业务和工作负载最有意义的时候执行切换操作，将全球数据库失效自动恢复到原始主区域。为此，请按照对 Amazon Aurora Global Database 执行切换中的步骤进行操作。

您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 对 Aurora Global Database 进行失效转移。

在 Aurora 全球数据库上执行托管式失效转移

1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/。

2. 选择数据库，然后找到要进行失效转移的 Aurora 全局数据库。

3. 从操作菜单中选择切换或失效转移全球数据库。

   

4. 选择失效转移（允许数据丢失）。

   

5. 对于新的主集群，选择其中一个辅助 Amazon Web Services 区域中的活动集群作为新的主集群。

6. 输入 confirm，然后选择确认。

失效转移完成后，您可以在数据库列表中查看 Aurora 数据库集群及其当前状态，如下图所示。

在 Aurora 全球数据库上执行托管式失效转移

使用 failover-global-cluster CLI 命令对 Aurora Global Database 进行失效转移。使用命令，传递下列参数的值。

• --region – 指定一个 Amazon Web Services 区域，这是您希望成为 Aurora 全球数据库的新主数据库集群的辅助数据库集群正在运行的位置。

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

• --target-db-cluster-identifier – 指定要提升为 Aurora 全球数据库的新主数据库集群的 Aurora 数据库集群的 Amazon 资源名称（ARN）。

• --allow-data-loss – 显式使其成为失效转移操作而不是切换操作。如果异步复制组件尚未完成将所有复制的数据发送到辅助区域，则失效转移操作可能会导致一些数据丢失。

对于 Linux、macOS 或 Unix：

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

对于 Windows：

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

要对 Aurora Global Database 进行失效转移，请运行 FailoverGlobalCluster API 操作。

执行 Aurora 全球数据库的手动失效转移

在某些情况下，您可能无法使用托管式失效转移过程。例如，如果您的主数据库集群和辅助数据库集群运行的引擎版本不兼容。在这种情况下，您可以按照此手动过程，失效转移到目标辅助区域。

确保在进行这些更改之前、期间和之后，将应用程序写入发送到正确的 Aurora 数据库集群。这样做可以避免 Aurora Global Database 中数据库集群之间的数据不一致（脑裂问题）。

如果您为响应 Amazon Web Services 区域中的中断进行了重新配置，则可以在解决中断后再次将 Amazon Web Services 区域设置为主区域。为此，您需要将旧的 Amazon Web Services 区域添加到新的全球数据库中，然后使用切换过程以切换其角色。您的 Aurora 全球数据库必须使用支持切换的 Aurora PostgreSQL 或 Aurora MySQL 版本。有关更多信息，请参阅 对 Amazon Aurora Global Database 执行切换。

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

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

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

当您的数据库在发生故障转移后在新 Amazon Web Services 区域 中恢复运行时，将使用 RPO。Aurora 会按如下方式评估 RPO 和 RPO 滞后时间，以便在主数据库集群上提交（或阻止）交易：

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

rds.global_db_rpo 参数是动态的。如果您决定在滞后充分减少之前不希望所有写入事务都停滞不前，则可以快速将其重置。在这种情况下，Aurora 会在短暂延迟后识别并实施更改。

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

设置恢复点目标

该 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 的全局数据库设置此值。

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"

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"

查看恢复点目标

全局数据库的恢复点目标 (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 获取集群的所有 rds.global_db_rpo 参数的值，以便了解 user 是否在任何 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-engine 或 system 数据库集群参数）返回与以下内容类似的输出。

{
    "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"
            ]
        }
    ]
}

要了解有关查看集群参数组的参数的更多信息，请参阅 在 Amazon Aurora 中查看数据库集群参数组的参数值。

禁用恢复点目标

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

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"

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"