在 Amazon Aurora 全球数据库中使用切换或失效转移

与 Aurora 数据库集群在单个 AWS 区域中提供的标准高可用性相比，Aurora 全球数据库提供了更高的业务连续性和灾难恢复（BCDR）保护。通过使用 Aurora 全球数据库，您可以针对真实的区域性灾难或完全的服务级别中断快速进行规划，并从中恢复。从灾难中恢复通常由以下两个业务目标驱动：

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

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

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

在灾难恢复情况下，有两种方法可以进行失效转移：

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

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

在托管式失效转移期间，主集群会失效转移到您选择的辅助区域，同时维护 Aurora 全球数据库的现有复制拓扑。所选的辅助集群将其一个只读节点提升为完全写入器状态。此步骤允许集群代入主集群的角色。在此集群代入其新角色期间，您的数据库在短时间内不可用。当该辅助集群成为新的主集群时，未从旧的主集群复制到选定辅助集群的数据将丢失。

为最大限度地减少数据丢失，我们建议您在使用此特征之前执行以下操作：

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

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

由于 Aurora 全球数据库使用异步复制，因此每个辅助区域的复制滞后可能会有所不同。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。

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

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

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

您可以使用AWS Management Console、AWS CLI 或 RDS API 对 Aurora Global Database 进行故障转移。

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

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

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

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

   

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

   

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

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

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

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

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

• --region – 指定一个 AWS 区域，这是您希望成为 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 全局数据库进行故障转移，请运行 FailoverGlobalCluster API 操作。

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

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

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

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

对 Amazon Aurora 全球数据库执行切换

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

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

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

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

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

切换过程完成后，提升后的 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。

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

您可以使用 AWS Management Console、AWS CLI 或 RDS API 对 Aurora 全球数据库进行切换。

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

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

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

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

   

4. 选择切换。

   

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

6. 选择确认。

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

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

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

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

• --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 全球数据库，请运行 SwitchoverGlobalCluster API 操作。

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

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

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

当您的数据库在发生故障转移后在新 AWS 区域 中恢复运行时，将使用 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。

您可以使用AWS Management Console、AWS 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 参数。您可以使用 AWS Management Console、AWS 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"