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

管理 Aurora 全局数据库

您可以对构成 Aurora 全局数据库的各个集群执行大多数的管理操作。在控制台中的数据库页面上选择对相关资源分组时,将会看到主集群和辅助集群分组到关联的全局数据库对象之下。


        屏幕截图显示如何在 AWS 管理控制台的“数据库”页面中表示 Aurora 全局数据库。

要查看适用于整个 Aurora 全局数据库的属性,则选择该全局数据库。



        显示 AWS 管理控制台中的所选 Aurora 全局数据库和关联设置的屏幕截图

配置 Aurora 全局数据库

AWS 管理控制台中的 Databases (数据库) 页面列出您所有的 Aurora 全局数据库,同时显示每个全局数据库的主集群和辅助集群。Aurora 全局数据库是具有自己的配置设置的对象,尤其是与主集群和辅助集群关联的 AWS 区域设置。下面是一个 Aurora MySQL 示例。


        显示 AWS 管理控制台中的所选 Aurora 全局数据库和关联配置设置的屏幕截图。

您可以选择 Aurora 全局数据库并修改其设置,如下面的屏幕截图中所示。


        屏幕截图显示 Aurora 全局数据库的修改设置页面。

您可以为 Aurora 全局数据库中的每个 Aurora 集群独立配置参数组。大多数参数的工作方式与其他类型的 Aurora 集群相同。我们建议在全局数据库中的所有集群间保持设置一致,以避免在将辅助集群提升到主集群时出现意外的行为变化。例如,对于时区和字符集使用相同设置,可避免在不同集群作为主集群时出现不一致的行为。

aurora_enable_repl_bin_log_filteringaurora_enable_replica_log_compression 配置设置没有效果。

监控 Aurora 全局数据库

要查看全局数据库的状态,请使用 aurora_global_db_statusaurora_global_db_instance_status 函数。

注意

仅 Aurora PostgreSQL 支持 aurora_global_db_statusaurora_global_db_instance_status 函数。

监控全局数据库

  1. 使用 PostgreSQL 实用工具(如 psql)连接到全局数据库主集群终端节点。有关如何连接的更多信息,请参阅 连接到 Aurora 全局数据库

  2. 在 psql 命令中使用 aurora_global_db_status 函数列出主卷和辅助卷。这显示全局数据库辅助数据库集群的滞后时间。

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin ------------+---------------------+------------------------+-----------------+----------------------------+----------------+--------------- us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0 us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243 (2 rows)

    输出包含全局数据库的每个数据库集群行,其中包含以下列:

    • aws_region – 此数据库集群所在的 AWS 区域。有关按引擎列出 AWS 区域的表,请参阅区域和可用区

    • highest_lsn_written – 当前在此数据库集群上写入的最高日志序列号 (LSN)。

      日志序列号 (LSN) 是标识数据库事务日志中的记录的唯一序列号。对 LSN 进行排序,以便较大的 LSN 表示较晚的事务。

    • durability_lag_in_msec – 辅助数据库集群上写入的最高日志序列号 (highest_lsn_written) 与主数据库集群上的 highest_lsn_written 之间的时间戳差异。

    • rpo_lag_in_msec – 恢复点目标 (RPO) 滞后。此滞后是存储在辅助数据库集群上的最新用户事务提交与存储在主数据库集群上的最新用户事务提交之间的时差。

    • last_lag_calculation_time – 最后为 replication_lag_in_msecrpo_lag_in_msec 计算值的时间戳。

    • feedback_epoch – 辅助数据库集群在生成热备用信息时使用的纪元。

      热备用 是指在服务器处于恢复或备用模式时,数据库集群可以进行连接和查询。热备用反馈是有关处于热备用状态的数据库集群的信息。有关更多信息,请参阅 PostgreSQL 文档中的热备用

    • feedback_xmin – 辅助数据库集群使用的最小(最早)活动事务 ID。

  3. 使用 aurora_global_db_instance_status 函数列出主数据库集群和辅助数据库集群的所有辅助数据库实例。

    postgres=> select * from aurora_global_db_instance_status();
    server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec --------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------ apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | | apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10 apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017 (3 rows)

    输出包含全局数据库的每个数据库实例行,其中包含以下列:

    • server_id – 数据库实例的服务器标识符。

    • session_id – 当前会话的唯一标识符。

    • aws_region – 此数据库实例所在的 AWS 区域。有关按引擎列出 AWS 区域的表,请参阅区域和可用区

    • durable_lsn – 存储中持久的 LSN。

    • highest_lsn_rcvd – 数据库实例从写入器数据库实例收到的最高 LSN。

    • feedback_epoch – 数据库实例在生成热备用信息时使用的纪元。

      热备用是指在服务器处于恢复或备用模式时,数据库实例可以进行连接和查询。热备用反馈是有关处于热备用状态的数据库实例的信息。有关更多信息,请参阅有关热备用 的 PostgreSQL 文档。

    • feedback_xmin – 数据库实例使用的最小(最早)活动事务 ID。

    • oldest_read_view_lsn – 数据库实例用于从存储中读取的最早 LSN。

    • visibility_lag_in_msec – 此数据库实例落后于写入器数据库实例的程度。

要查看这些值如何随时间变化,请考虑以下事务块,其中表插入需要一个小时。

psql> BEGIN; psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; psql> COMMIT;

在某些情况下,在 BEGIN 语句之后主数据库集群和辅助数据库集群之间的网络会断开连接。如果是这样,辅助数据库集群的 replication_lag_in_msec 值开始增加。在 INSERT 语句的末尾,replication_lag_in_msec 值为 1 小时。但是,rpo_lag_in_msec 值为 0,因为在主数据库集群和辅助数据库集群之间提交的所有用户数据仍然相同。在 COMMIT 语句完成后,rpo_lag_in_msec 值会立即增加。

Aurora 全局数据库的跨区域灾难恢复

在某些情况下,您的 Aurora 全局数据库可能包含多个辅助 AWS 区域。如果是这样,您可以选择在中断影响主 AWS 区域时故障转移到哪个 AWS 区域。为了帮助确定选择哪个辅助 AWS 区域,您可以监控所有辅助区域的复制滞后。在某些情况下,一个辅助区域的复制滞后可能比其他区域少很多。如果是这样,这很好地说明关联的 Aurora 集群有足够的数据库和网络容量来接管应用程序的全部读/写工作负载。

当全局数据库具有多个辅助区域时,如果主 AWS 区域发生中断,请确保分离所有辅助区域。然后,您将其中一个辅助区域提升为新的主 AWS 区域。最后,在其他每个辅助区域中创建新的集群,并将这些集群附加到全局数据库。

将辅助集群提升为主集群时,还需要更新应用程序用于连接到全局数据库的终端节点。要从新提升的集群获取新的写入器终端节点,可以通过从终端节点字符串中删除 -ro 来转换以前的读取器终端节点。例如,如果以前的读取器终端节点为 global-16rr-test-cluster-1.cluster-ro-12345678901.us-west-2.rds.amazonaws.com,则新提升的写入器终端节点为 global-16rr-test-cluster-1.cluster-cps2igpwyrwa.us-west-2.rds.amazonaws.com

Aurora 全局数据库故障转移

Aurora 全局数据库引入了比默认 Aurora 集群更高级别的故障转移功能。如果一个 AWS 区域中的整个集群变得不可用,则可以提升全局数据库中的另一个集群,使之具有读/写功能。

如果另一个 AWS 区域中的集群成为主集群效果更好,您可以手动启用故障转移机制。例如,您可以提高其中一个辅助集群的容量,然后将其提升成为主集群。或者 AWS 区域间的活动平衡可能发生变化,这样,将主集群切换到另一个 AWS 区域可能会对写入操作带来较低延迟。

以下过程概述了如何在 Aurora 全局数据库中提升其中一个辅助集群。

提升辅助集群

在开始此过程之前,主集群出现故障或以其他方式变为不可用。

  1. 从 Aurora 全局数据库移除辅助集群。这样做会将该集群提升到完全读写能力。要了解如何从全局数据库中移除 Aurora 集群,请参阅从 Aurora 全局数据库移除集群

  2. 重新配置应用程序,以使写入流量转向新提升的集群。

    重要

    此时,停止向变为不可用的集群发出任何 DML 语句或其他写入操作。要避免集群之间的数据不一致(称为“分裂大脑”场景),请避免写入以前的主集群,即使其重新回到在线状态。

  3. 创建新的 Aurora 全局数据库,并将新提升的集群用作主集群。要了解如何创建 Aurora 全局数据库,请参阅创建 Aurora 全局数据库

  4. 将遇到问题的集群的 AWS 区域添加到 Aurora 全局数据库。现在,AWS 区域包含新的辅助集群。要了解如何将 AWS 区域添加到 Aurora 全局数据库,请参阅将 AWS 区域添加到 Aurora 全局数据库

  5. 当停机问题已解决且您已准备好再次将原始 AWS 区域指定为主集群时,请按相反顺序执行相同步骤:

    1. 从 Aurora 全局数据库移除其中一个辅助集群。

    2. 让该集群成为原始 AWS 区域中新的 Aurora 全局数据库的主集群。

    3. 将所有写入流量重定向到原始 AWS 区域中的主集群。

    4. 添加 AWS 区域,以便在与之前相同的 AWS 区域中设置一个或多个辅助集群。

管理 Aurora 全局数据库的恢复

在发生影响主数据库集群的网络或硬件故障等灾难时,您可以控制全局数据库恢复的点。您可以通过为全局数据库设置恢复点目标 (RPO) 来管理恢复。

注意

与 PostgreSQL 兼容的 Amazon Aurora 目前支持管理 RPO。有关受支持的 Aurora PostgreSQL 版本和 AWS 区域的列表,请参阅 Aurora 全局数据库的限制

恢复点目标 是您希望可从辅助数据库集群恢复的数据的最早时间。当您的数据库在故障转移后在新的 AWS 区域中恢复操作时,将使用 RPO。它表示您愿意接受的数据库故障转移后以时间测量的数据丢失量。

通过使用托管 RPO,您可以控制最大数据丢失量,因为辅助数据库集群落后于主数据库集群。此数据丢失以时间进行测量,称为 RPO 滞后时间。 当您设置 RPO 时,Aurora PostgreSQL 会在全局数据库上实施它,如下所示:

  1. 如果至少一个辅助数据库集群的 RPO 滞后时间小于 RPO 时间,则 Aurora PostgreSQL 允许在主数据库集群上提交事务。

  2. 如果没有辅助数据库集群的 RPO 滞后时间小于 RPO 时间,则 Aurora PostgreSQL 会阻止事务提交。如果 Aurora PostgreSQL 开始阻止提交,则会在 PostgreSQL 日志文件中插入一个事件。然后,它会发出显示被阻止的会话的等待事件。

  3. 当至少一个辅助数据库集群的 RPO 滞后时间变得小于 RPO 时间时,Aurora PostgreSQL 再次允许在主数据库集群上提交事务。

这种方法可确保 Aurora PostgreSQL 不允许完成会导致违反您所选 RPO 时间的事务提交。

查看恢复点目标

全局数据库的恢复点目标 (RPO) 存储在 rds.global_db_rpo 参数中。要查看集群参数组的 rds.global_db_rpo 参数和其他参数的当前 RPO 设置,请参阅查看数据库集群参数组的参数值

设置恢复点目标

您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 设置全局数据库的 RPO。有关更多信息,请参阅修改数据库集群参数组中的参数

设置 RPO

  1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 标识全局数据库的主数据库集群的参数组。有关集群的配置设置的更多信息,请参阅 配置 Aurora 全局数据库

  3. 打开主数据库集群参数组并设置 rds.global_db_rpo 参数。有关更多信息,请参阅 修改数据库集群参数组中的参数

  4. rds.global_db_rpo 参数值设置为恢复点目标所需的秒数。有效值从 20 秒到最大整数值 2,147,483,647(68 年)。

要设置 rds.global_db_rpo 参数,请使用 AWS CLI,使用 modify-db-cluster-parameter-group 命令。

以下示例将名为 global_db_cluster_parameter_group 的主数据库集群参数组的 RPO 设置为 5000 秒。有效值从 20 秒到最大整数值 2,147,483,647(68 年)。

对于 Linux、macOS 或 Unix:

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

对于 Windows:

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

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

禁用恢复点目标

要禁用 RPO,请重置 rds.global_db_rpo 参数。您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 重置参数。

禁用 RPO

  1. 登录 AWS 管理控制台 并通过以下网址打开 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 操作。

Aurora 全局数据库的 Performance Insights

您可以同时使用 Amazon RDS Performance Insights 和 Aurora 全局数据库。这样,可将 Performance Insights 报告分别应用于全局数据库中的每个集群。您可以针对全局数据库中的每个集群启用或禁用 Performance Insights 功能。在将新的辅助 AWS 区域添加到已在使用 Performance Insights 的全局数据库时,确保在新添加的集群中启用 Performance Insights。此集群不能从现有全局数据库继承 Performance Insights 设置。

在查看附加到全局数据库的数据库实例的 Performance Insights 页面时,您可以切换 AWS 区域。但是,您可能不能在切换 AWS 区域后立即看到性能详情。在各 AWS 区域中,虽然数据库实例的名称可能会相同,但每个数据库实例的相关 Performance Insights URL 不同。在切换 AWS 区域后,可在 Performance Insights 导航窗格中重新选择数据库实例的名称。

对于与全局数据库关联的数据库实例,各 AWS 区域中影响性能的系数可能不同。例如,各 AWS 区域中数据库实例的容量可能不同。

有关使用 Performance Insights 的信息,请参阅使用 Amazon RDS Performance Insights

从 Aurora 全局数据库移除集群

从 Aurora 全局数据库移除 Aurora 集群会将其转变回区域集群,具有完全读/写能力且不再与主集群同步。

当主集群变为降级或隔离后,您可以从全局数据库移除 Aurora 集群。对 Aurora 全局数据库执行故障转移涉及从原始全局数据库中移除其中一个辅助集群。然后将该集群用作新 Aurora 全局数据库中的主集群。有关更多信息,请参阅Aurora 全局数据库故障转移

如果您不再需要全局数据库,请确保在删除全局数据库自身之前,必须先移除所有辅助集群,然后移除主集群。然后,您可以删除所移除的部分或全部集群,或者继续将部分或全部集群用作单区域 Aurora 集群。有关更多信息,请参阅删除 Aurora 全局数据库

从 Aurora 全局数据库删除 Aurora 集群

  1. Databases (数据库) 页面上选择集群。

  2. 对于 Actions (操作),选择 Remove from Global (从全局数据库移除)。移除的集群将成为具有完全读/写能力的常规 Aurora 集群。它不再与主集群保持同步。

    
            屏幕截图显示从 Aurora 全局数据库中移除辅助集群的确认提示。

    如有任何辅助集群仍与全局数据库关联,则无法移除主集群。

    在移除或删除所有辅助集群后,您可以按同样方式移除主集群。

从 Aurora 全局数据库移除集群之后,您仍可以在 Databases (数据库) 页面中看到它们,但没有 Global (全局)Primary (主)Secondary (辅助) 标签。


            屏幕截图显示从 Aurora 全局数据库中移除之后的集群。

要使用 AWS CLI 从 Aurora 全局数据库移除 Aurora 集群,请运行 remove-from-global-cluster 命令。

以下命令从 Aurora 全局数据库中移除辅助集群,然后移除主集群。在每种情况下,要移除的集群均由 --db-cluster-identifier 参数标识。Aurora 全局数据库由 --global-cluster-identifier 参数标识。

对于 Linux、macOS 或 Unix:

aws rds --region secondary_region \ remove-from-global-cluster \ --db-cluster-identifier secondary_cluster_ARN \ --global-cluster-identifier global_database_id ... repeat above command with a different --region for all secondary clusters ... aws rds --region primary_region \ remove-from-global-cluster \ --db-cluster-identifier primary_cluster_ARN \ --global-cluster-identifier global_database_id

对于 Windows:

aws rds --region secondary_region ^ remove-from-global-cluster ^ --db-cluster-identifier secondary_cluster_ARN ^ --global-cluster-identifier global_database_id ... repeat above command with a different --region for all secondary clusters ... aws rds --region primary_region ^ remove-from-global-cluster ^ --db-cluster-identifier primary_cluster_ARN ^ --global-cluster-identifier global_database_id

要使用 RDS API 从 Aurora 全局数据库移除 Aurora 集群,请运行 RemoveFromGlobalCluster 操作。

删除 Aurora 全局数据库

在删除 Aurora 全局数据库之前,请确保必须先移除或删除全局数据库的集群。由于全局数据库通常容纳业务关键数据,因此您不能一步删除全局数据库和关联的集群。有关如何从全局数据库中移除集群(此操作使集群再次成为独立 Aurora 集群)的说明,请参阅从 Aurora 全局数据库移除集群。有关演示如何在移除集群后删除集群的过程,请参阅删除 Aurora 数据库集群中的数据库实例

要使用 AWS 管理控制台删除 Aurora 全局数据库,应先移除或删除与全局数据库关联的所有辅助集群。然后移除主集群,最终删除全局数据库本身。

从 Aurora 集群中删除写入器实例将删除集群本身。由于全局数据库通常容纳业务关键数据,因此您不能一步删除全局数据库和关联的集群。

有关从全局数据库移除集群的说明,请参阅从 Aurora 全局数据库移除集群。有关显示如何在移除集群后删除集群的过程,请参阅删除 Aurora 数据库集群中的数据库实例。从 Aurora 集群中删除主实例将删除集群本身。

使用 AWS 管理控制台删除 Aurora 全局数据库

  1. 确认所有其他集群从 Aurora 全局数据库中移除。

    如果全局数据库中嵌套了任何集群(如下面的屏幕截图所示),则尚无法删除全局数据库。对于与全局数据库关联的每个集群,按照从 Aurora 全局数据库移除集群中介绍的过程操作。

    
                无法删除前面显示的全局数据库,因为它仍有关联的集群。

    在全局数据库没有任何关联的集群后,您才可以删除它。下面的屏幕截图显示 global-db-demo 集群在移除后不再与全局数据库关联。

    
                所有集群从全局数据库中移除,因此现在可以删除它。
  2. Databases (数据库) 页面或全局数据库的详细信息页面上,为 Actions (操作) 选择 Delete (删除)

要使用 AWS CLI 删除作为 Aurora 全局数据库一部分的集群,请运行 delete-global-cluster 命令。

以下命令删除具有指定全局集群 ID 的 Aurora 全局数据库。

对于 Linux、macOS 或 Unix:

aws rds --region primary_region \ delete-global-cluster \ --global-cluster-identifier global_database_id

对于 Windows:

aws rds --region primary_region ^ delete-global-cluster ^ --global-cluster-identifier global_database_id

要使用 RDS API 删除作为 Aurora 全局数据库一部分的集群,请运行 DeleteGlobalCluster 操作。