在 Amazon Aurora 全球数据库中使用切换或失效转移 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

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

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

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

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

  • 失效转移 – 使用此方法从计划外停机中恢复。使用这种方法,您可以跨区域失效转移到 Aurora 全球数据库中的一个辅助数据库集群。这种方法的 RPO 通常是一个以秒为单位的非零值。数据丢失量取决于发生故障时跨 Amazon Web Services 区域的 Aurora 全球数据库复制滞后。要了解更多信息,请参阅 从计划外停机中恢复 Amazon Aurora Global Database

  • 切换 – 此操作以前称为“托管式计划内失效转移”。将此方法用于受控场景,例如操作维护和其他计划内操作过程。由于此特征会在进行任何其他更改之前将辅助数据库集群与主数据库集群同步,因此 RPO 为 0(不会造成数据丢失)。要了解更多信息,请参阅 对 Amazon Aurora 全球数据库执行切换

注意

如果要切换或失效转移到无管控辅助 Aurora 数据库集群,则需要先向它添加一个数据库实例。有关无管控数据库集群的更多信息,请参阅在辅助区域中创建无管控 Aurora 数据库集群

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

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

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

  • 托管式失效转移 - 建议使用此方法进行灾难恢复。使用此方法时,当旧的主区域再次变为可用时,Aurora 会自动将其作为辅助区域重新添加到全球数据库中。因此,您的全球集群的原始拓扑保持不变。要了解如何使用此方法,请参阅执行 Aurora 全球数据库的托管式失效转移

  • 手动失效转移 – 当无法选择托管式失效转移时,例如,当您的主区域和辅助区域运行不兼容的引擎版本时,可以使用这种替代方法。要了解如何使用此方法,请参阅执行 Aurora 全球数据库的手动失效转移

重要

这两种失效转移方法都可能导致在失效转移事件发生之前,未复制到选定辅助系统的写入事务数据丢失。但是,将所选辅助数据库集群上的数据库实例提升为主写入器数据库实例的恢复过程可确保数据处于事务一致状态。

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

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

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

注意

仅当主数据库集群和辅助数据库集群具有相同的主要、次要和补丁级别引擎版本时,您才能对 Aurora 全局数据库执行托管式跨区域数据库失效转移。但是,补丁级别可能会有所不同,具体取决于次要引擎版本。有关更多信息,请参阅托管式跨区域切换和失效转移的补丁级别兼容性。如果您的引擎版本不兼容,则可以按照执行 Aurora 全球数据库的手动失效转移中的步骤手动执行失效转移。

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

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

  • 检查 Aurora 全局数据库中所有辅助 Aurora 数据库集群的滞后时间。选择复制滞后最小的辅助区域可以最大限度地减少当前出现故障的主区域的数据丢失。对于所有基于 Aurora PostgreSQL 的全球数据库以及从引擎版本 3.04.0 及更高版本或 2.12.0 及更高版本开始的基于 Aurora MySQL 的全球数据库,请使用 Amazon CloudWatch 查看所有辅助数据库集群的 AuroraGlobalDBRPOLag 指标。对于基于 Aurora MySQL 的全球数据库的较低次要版本,请改为查看 AuroraGlobalDBReplicationLag 指标。这些指标显示复制到辅助集群滞后于复制到主数据库集群的时间(以毫秒为单位)。

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

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

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

  • 配置监控工具和选项(例如 Amazon CloudWatch Events 和警报)– 根据全局数据库的需要,为提升后的数据库集群配置相同的日志记录能力、警报等等。与参数组一样,在故障转移过程中,这些特征的配置不会从主数据库集群继承。一些 CloudWatch 指标(例如复制滞后)仅适用于辅助区域。因此,失效转移会更改查看这些指标和对指标设置警报的方式,并且可能要求更改任何预定义的控制面板。有关 Aurora 数据库集群和监控的更多信息,请参阅 Amazon Aurora 监控概览

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

通常,所选的辅助集群会在几分钟内代入主角色。一旦新的主区域的写入器节点可用,您就可以将应用程序连接到该节点并恢复工作负载。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”的这一快照放入 Amazon Web Services Management Console的快照部分中。还可以在 DescribeDBClusterSnapshots API 操作返回的信息中看到列出的此快照。

注意

旧存储卷的快照是系统快照,受旧的主集群上配置的备份保留期限制。要在保留期之外保留此快照,可以复制它以另存为手动快照。要了解有关复制快照的更多信息(包括定价),请参阅复制数据库集群快照

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

您可以使用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. 选择 Databases(数据库),然后找到要进行故障转移的 Aurora 全局数据库。

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

    
                    显示“数据库”列表,其中选定了全球数据库;并了打开“操作”菜单,其中显示“切换或失效转移全球数据库”选项。
  4. 选择失效转移(允许数据丢失)

    
                 “切换或失效转移全球数据库”对话框,选择了“失效转移(允许数据丢失)”。
  5. 对于新的主集群,选择其中一个辅助 Amazon Web Services 区域中的活动集群作为新的主集群。

  6. 输入 confirm,然后选择确认

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


                显示选择了全球数据库的“数据库”列表。选定的辅助集群现在显示为具有主集群角色,而旧的主集群具有辅助集群的角色。

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

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

  • --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 全局数据库进行故障转移,请运行 FailoverGlobalCluster API 操作。

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

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

提示

我们建议您在实施此过程之前先了解此过程。准备好计划,以便在区域级问题初见端倪时快速处理。通过定期使用 Amazon CloudWatch 来跟踪辅助集群的滞后时间,您就可以确定复制滞后最少的辅助区域。确保测试计划,以检查您的过程是否完整和准确,并确保员工在灾难恢复失效转移真正发生之前接受了相关培训以执行此失效转移过程。

在主区域发生计划外停机后,手动失效转移到辅助集群
  1. 停止向停机的 Amazon Web Services 区域 中的主 Aurora 数据库集群发出 DML 语句和其他写入操作。

  2. 从辅助 Amazon Web Services 区域 中标识作为新的主数据库集群的 Aurora 数据库集群。如果您的 Aurora 全球数据库中有两个或更多辅助 Amazon Web Services 区域,请选择复制滞后最少的辅助集群。

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

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

    有关分离的详细步骤,请参阅 从 Amazon Aurora Global Database 删除集群

  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 Global Database 的主集群。

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

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

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

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

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

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

注意

切换以前称为“托管式计划内失效转移”。

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

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

  • 适用于对特定行业施加的“区域轮换”要求。例如,金融服务法规可能要求第 0 层系统在几个月内切换到不同的区域,以确保定期执行灾难恢复过程。

  • 适用于多区域“全天候”应用程序。例如,一家企业可能希望根据不同时区的工作时间在不同区域提供延迟更低的写入。

  • 作为一种零数据丢失方法,可在失效转移后失效自动恢复到原始主区域。

注意

切换功能专为在正常运行的 Aurora 全球数据库上使用而设计。要从计划外停机中进行恢复,请按照从计划外停机中恢复 Amazon Aurora Global Database中的相应过程操作。

要执行切换,您的目标辅助数据库集群必须运行与主数据库集群完全相同的引擎版本(包括补丁级别),具体取决于引擎版本。有关更多信息,请参阅托管式跨区域切换和失效转移的补丁级别兼容性。在开始切换之前,请检查全球集群中的引擎版本,以确保它们支持托管式跨区域切换,并在需要时对其进行升级。

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

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

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

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

  • 检查 Aurora 全局数据库中所有辅助 Aurora 数据库集群的滞后时间。对于所有基于 Aurora PostgreSQL 的全球数据库以及从引擎版本 3.04.0 及更高版本或 2.12.0 及更高版本开始的基于 Aurora MySQL 的全球数据库,请使用 Amazon CloudWatch 查看所有辅助数据库集群的 AuroraGlobalDBRPOLag 指标。对于基于 Aurora MySQL 的全球数据库的较低次要版本,请改为查看 AuroraGlobalDBReplicationLag 指标。这些指标显示复制到辅助集群滞后于复制到主数据库集群的时间(以毫秒为单位)。该值与 Aurora 完成切换所需的时间成正比。因此,滞后值越大,切换所需的时间就越长。

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

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

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

  • 配置监控工具和选项(例如 Amazon CloudWatch Events 和警报)– 根据全局数据库的需要,为提升后的数据库集群配置相同的日志记录能力、警报等等。与参数组一样,在切换过程中,这些特征的配置不会从主数据库集群继承。一些 CloudWatch 指标(例如复制滞后)仅适用于辅助区域。因此,切换会更改查看这些指标和对指标设置警报的方式,并且可能要求更改任何预定义的控制面板。有关 Aurora 数据库集群和监控的更多信息,请参阅 Amazon Aurora 监控概览

  • 配置与其他 Amazon 服务的集成 - 如果您的 Aurora 全球数据库与 Amazon 服务(例如 Amazon Secrets Manager、Amazon Identity and Access Management、Amazon S3 和 Amazon Lambda)集成,则确保根据需要配置与这些服务的集成。有关将 Aurora Global Database 与 IAM、Amazon S3 和 Lambda 集成的更多信息,请参阅 将 Amazon Aurora Global Database 与其他Amazon服务结合使用。要了解有关 Secrets Manager 的更多信息,请参阅如何跨 Amazon Web Services 区域 自动复制 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

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

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

对您的 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 全球数据库进行切换。使用命令,传递下列参数的值。

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

管理基于 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 滞后时间小于 RPO,则提交事务。

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

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

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

重要

在只有两个区域的全球数据库中,我们建议在辅助区域的参数组中保留 rds.global_db_rpo 参数的原定设置值。否则,由于主区域丢失而导致失效转移到该区域可能会导致 Aurora 暂停事务。相反,请等待 Aurora 在旧的故障区域中完成集群重建,然后更改此参数以实施最大 RPO。

如果按下述设置此参数,则还可以监控其生成的指标。您可以通过使用 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 的全局数据库设置此值。

设置 RPO
  1. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/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 获取集群的所有 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-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.aws.amazon.com/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 操作。