使用 Amazon Aurora Global Database - Amazon Aurora
Aurora Global Database 概览Amazon Aurora Global Database 的优势区域和版本可用性Aurora Global Database 的限制

使用 Amazon Aurora Global Database

使用 Amazon Aurora Global Database 特征，您可以设置跨多个 AWS 区域的多个 Aurora 数据库集群。Aurora 会自动将主数据库集群中进行的所有更改同步到一个或多个辅助集群。一个 Aurora 全局数据库在一个区域中有一个主数据库集群，在不同区域中最多有五个辅助数据库集群。这种多区域配置可从可能影响整个 AWS 区域的罕见停机事件中快速恢复。如果多个地理位置中的所有数据有一个完整副本，那么对于从世界各地相距甚远的位置连接的应用程序，还可以实现低延迟读取操作。

主题

Amazon Aurora Global Database 概览

使用 Amazon Aurora Global Database 特征，您可以通过跨多个 AWS 区域的单个 Aurora 数据库来运行您的全局分布式应用程序。

Aurora Global Database 由一个写入数据的主 AWS 区域 和最多五个只读次 AWS 区域 组成。您可将写入操作发送到主 AWS 区域中的主数据库集群。一种极为便捷的方法是连接到 Aurora Global Database 写入器端点，该端点始终指向主数据库集群，即使在切换或失效转移到其他 AWS 区域之后也是如此。执行任何写入操作之后，Aurora 会将数据复制到使用专用基础设施的辅助 AWS 区域，延迟通常不到一秒。

下图显示了跨越两个 AWS 区域 的 Aurora Global Database 示例。

Aurora全局数据库只有一个主数据库集群，并有至少一个 Aurora 辅助数据库集群。

您可以通过添加一个或多个 Aurora 读取器实例以承担只读工作负载，从而独立地纵向扩展每个辅助集群。您可以对读取器实例使用 Aurora Serverless v2，以实现更精细和更灵活的扩展。

只有主集群才能执行写入操作。执行写入操作的客户端连接到 Aurora Global Database 写入器端点，该端点始终指向主集群的写入器数据库实例。如图所示，Aurora 使用集群存储卷（而不是数据库引擎）进行快速、低开销复制。要了解更多信息，请参阅 Amazon Aurora 存储概述。

Aurora Global Database 专为遍布全球的应用程序而设计。多个 AWS 区域中的只读辅助数据库集群有助于优化更靠近应用程序用户的读取操作。借助写入转发特征，您还可以配置全局数据库，以使辅助集群将写入请求发送到主集群。有关更多信息，请参阅 在 Amazon Aurora Global Database 中使用写入转发。

Aurora Global Database 支持两种不同的操作来更改主数据库集群的区域，具体视情况而定：Aurora Global Database 切换和 Aurora Global Database 失效转移。

  • 对于计划的操作过程（如区域轮换），请使用切换机制（以前称为“托管式计划失效转移”）。通过此特征，您可以将运行正常的 Aurora Global Database 的主集群重新放置到其辅助区域之一，而不会造成数据丢失。要了解更多信息，请参阅 对 Amazon Aurora Global Database 执行切换。

  • 要在主区域中发生停机后恢复 Aurora Global Database，请使用失效转移机制。通过此特征，您可以执行从主数据库集群到另一个区域的失效转移（跨区域失效转移）。要了解更多信息，请参阅 执行 Aurora 全球数据库的托管式失效转移。

Amazon Aurora Global Database 的优势

使用 Aurora Global Database，您可以获得以下优势：

  • 全局读取本地延迟 - 如果您在世界各地设有办事处，则可以使用 Aurora Global Database 在主 AWS 区域保持主要信息来源为最新状态。您其他区域的办事处可以访问各自区域中的信息，存在本地延迟。

  • 可扩展辅助 Aurora 数据库集群 - 您可以通过向辅助 AWS 区域添加更多只读实例来扩展辅助集群。辅助集群为只读模式，因此它最多可以支持 16 个只读数据库实例，而不符合单个 Aurora 集群通常 15 个此类实例的限制。

  • 从主到辅助 Aurora 数据库集群快速复制 - Aurora Global Database 执行的复制几乎不会影响主数据库集群的性能。数据库实例的资源完全专用于承担应用程序读取和写入工作负载。

  • 从区域范围内的中断中恢复 - 辅助集群使您能够比传统复制解决方案更快地（RTO 更低）在新的主 AWS 区域中使用 Aurora Global Database，并且数据损失更少（RPO 更低）。

区域和版本可用性

特征可用性和支持因每个 Aurora 数据库引擎的特定版本以及 AWS 区域而异。有关 Aurora Global Database 的版本和区域可用性的更多信息，请参阅支持 Aurora 全球数据库的区域和数据库引擎。

Amazon Aurora Global Database 的限制

以下限制目前适用于 Aurora Global Database：

  • Aurora Global Database 在某些 AWS 区域可用，且适用于特定 Aurora MySQL 和 Aurora PostgreSQL 版本。有关更多信息，请参阅 支持 Aurora 全球数据库的区域和数据库引擎。

  • Aurora Global Database 对于支持的 Aurora 数据库实例类、AWS 区域的最大数量等有特定的配置要求。有关更多信息，请参阅 Amazon Aurora Global Database 的配置要求。

  • 为了实现 Aurora MySQL 与 MySQL 5.7 兼容，Aurora Global Database 切换需要版本 2.09.1 或更高的次要版本。

  • 仅当主数据库集群和辅助数据库集群具有相同的主要和次要引擎版本时，您才能对 Aurora Global Database 执行托管式跨区域切换或失效转移。根据引擎和引擎版本，补丁级别可能需要相同，也可以不同。有关允许在具有不同补丁级别的主集群和辅助集群之间进行这些操作的引擎和引擎版本列表，请参阅托管式跨区域切换和失效转移的补丁级别兼容性。如果您的引擎版本需要相同的补丁级别，您可以按照执行 Aurora 全球数据库的手动失效转移中的步骤手动执行失效转移。

  • Aurora Global Database 目前不支持以下 Aurora 特征：

    • Aurora Serverless v1

    • 正在 Aurora 中回溯

  • 有关在 Aurora Global Database 中使用 RDS 代理特征的限制，请参阅对全局数据库使用 RDS 代理的限制。

  • 自动次要版本升级不适用于作为全局数据库一部分的 Aurora MySQL 和 Aurora PostgreSQL 集群。请注意，您可以为属于全局数据库集群的数据库实例指定该设置，但该设置无效。

  • Aurora Global Database 目前不支持辅助数据库集群的 Aurora Auto Scaling。

  • 要在运行 Aurora MySQL 5.7 的 Aurora Global Database 上使用数据库活动流（DAS），引擎版本必须为 2.08 或更高版本。有关 DAS 的信息，请参阅使用数据库活动流监控 Amazon Aurora。

  • 以下限制目前适用于升级 Aurora Global Database：

    • 在对该 Aurora 全局数据库执行主要版本升级时，无法将自定义参数组应用于全局数据库集群。您可以在全局集群的每个区域中创建自定义参数组，然后在升级后手动将它们应用于区域集群。

    • 使用基于 Aurora MySQL 的 Aurora 全局数据库时，如果开启了 lower_case_table_names 参数，则无法执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。有关可以使用的方法的更多信息，请参阅主要版本升级。

    • 使用 Aurora Global Database 时，如果启用了恢复点目标（RPO）特征，则无法对 Aurora PostgreSQL 数据库引擎执行主要版本升级。有关 RPO 特征的信息，请参阅 管理基于 Aurora PostgreSQL 的全局数据库的 RPO。

    • 使用 Aurora Global Database 时，您无法使用标准流程执行从 Aurora MySQL 版本 3.01 或 3.02 到 3.03 或更高版本的次要版本升级。有关要使用的过程的详细信息，请参阅通过修改引擎版本升级 Aurora MySQL。

    有关升级 Aurora Global Database 的信息，请参阅 升级 Amazon Aurora Global Database。

  • 您无法单独地停止或启动全局数据库中的 Aurora 数据库集群。要了解更多信息，请参阅 停止和启动 Amazon Aurora 数据库集群。

  • 在某些情况下，附加到辅助 Aurora 数据库集群的 Aurora 读取器数据库实例可能会重新启动。如果主 AWS 区域的写入器数据库实例重新启动或发生失效转移，则辅助区域中的读取器数据库实例也会重新启动。随后辅助集群将不可用，直到所有读取器数据库实例与主数据库集群的写入器实例恢复同步。重启或失效转移时主集群的行为与单个非全局数据库集群的行为相同。有关更多信息，请参阅 使用 Amazon Aurora 进行复制。

    在更改主数据库集群之前，请务必了解对 全局数据库的影响。要了解更多信息，请参阅 从计划外停机中恢复 Amazon Aurora Global Database。

  • 当 Amazon Aurora 无法访问数据库集群的 AWS KMS 密钥时，Aurora Global Database 目前不支持 inaccessible-encryption-credentials-recoverable 状态。在这些情况下，加密的数据库集群会直接进入最终 inaccessible-encryption-credentials 状态。有关这些状态的更多信息，请参阅 查看数据库集群状态。

  • 使用 Aurora Global Database 的基于 Aurora PostgreSQL 的数据库集群存在以下限制：

    • 作为 Aurora 全局数据库一部分的 Aurora PostgreSQL 数据库集群不支持集群缓存管理。

    • 如果全局数据库的主数据库集群基于 Amazon RDS PostgreSQL 实例的副本，则无法创建辅助集群。切勿尝试使用 AWS Management Console、AWS CLI 或 CreateDBCluster API 操作从该集群创建辅助。尝试这样做会超时，也不会创建辅助集群。

我们建议您使用与主数据库相同版本的 Aurora 数据库引擎为全局数据库创建辅助数据库集群。有关更多信息，请参阅 创建 Amazon Aurora Global Database。