亚马逊AWS官方博客

使用 Aurora Global Database 以尽可能短的停机时间在各个 AWS 区域迁移 Amazon Aurora

借助 Aurora Global Database，单个 Aurora 数据库可以跨越多个 AWS 区域，从而使分布在全球的应用程序能够在每个区域快速进行本地读取。它通过专用基础设施上基于存储的复制，实现了亚秒级的跨区域延迟。基于存储的复制功能使您的数据库实例可以完全专注于处理应用程序读取和写入工作负载。一个 Aurora 全局数据库在一个区域中有一个主数据库集群，在不同的区域中最多可以有五个辅助数据库集群。万一您的主区域出现性能下降或中断情况，您可以在一分钟内将其中一个辅助区域提升为承担读/写职责。

出于各种原因（例如迁移到离客户更近的地区、法规要求、业务要求的变化或客户人口统计信息），您可能需要将 Aurora 数据库从一个区域迁移到另一个区域。您可以使用多种方法来完成迁移，包括跨区域快照复制、逻辑复制、逻辑转储还原或 AWS Database Migration Service（AWS DMS），但缺点是它们要么需要付出更多的努力，要么需要更长的停机时间。

在这篇文章中，我们使用了 Aurora Global Database 的托管计划失效转移功能来将 Aurora 数据库迁移到另一个区域，该功能可尽量减少所需的工作量和停机时间。托管计划失效转移功能设计用于受控环境，例如用于运营维护和其他计划的运营过程，并使用 Aurora Global Database 的复制拓扑将主集群失效转移到您选择的辅助区域，而不会丢失数据。

解决方案概览

在本演练中，我们使用 Aurora Global Database 的跨区域失效转移功能将 Amazon Aurora PostgreSQL 兼容版本数据库从 us-east-1（源区域）迁移到 ca-central-1（目标区域）。

大致步骤如下所示：

  1. 将 ca-central-1（目标区域）作为辅助区域添加到您的 Aurora 数据库中。这将创建 Aurora 全局数据库。
  2. 将全局数据库失效转移到辅助区域。
  3. 从全局数据库移除源区域（us-east-1）中的 Aurora 集群。
  4. 从全局数据库移除目标区域（ca-central-1) ）中的 Aurora 集群。这将创建您的目标 Aurora 集群。

先决条件

此解决方案的先决条件包括：

限制

在迁移之前，请查看 Aurora 全局数据库的限制。在某些情况下，这些限制可能会使此方法无法用于数据库迁移。在其他情况下，可能仅在迁移的生命周期内才存在该限制。部分限制如下：

  • 在执行本演练中的步骤之前，请将 Aurora 数据库更改为与 Aurora 全局数据库兼容的实例类。迁移后，您可以恢复为原始实例类。
  • 在执行本演练中的步骤之前，请先禁用 Aurora 数据库的 Amazon RDS 代理。迁移后，您可以重新启用 RDS 代理。
  • Aurora 多主集群、Amazon Aurora Serverless v1 和回溯不适用于 Aurora 全局数据库，即使在迁移后也无法启用。

将辅助区域添加到您的 Aurora 数据库

要向数据库中添加辅助区域，请完成以下步骤：

  1. 在 Amazon RDS 控制台的导航窗格中，选择 Databases（数据库）。
  2. 选择源 Aurora 集群，然后在 Actions（操作）菜单上选择 Add AWS Region（添加 AWS 区域）。
  3. 填写辅助 Aurora 集群所需的详细信息，例如全局数据库标识符、辅助区域、实例类等。这最终将成为您的目标 Aurora 集群。您可能希望模仿源实例的设置，以便在迁移完成后拥有与源区域相同的数据库容量和配置。
  4. 选择 Add Region（添加区域）。

这样即可创建您的 Aurora 全局数据库。它显示在 Databases（数据库）页面上，如以下屏幕截图所示。

记得配置辅助 Aurora 集群，以便从主 Aurora 集群复制选项。这些配置选项包括只读副本设置、集群参数和选项组、监控机制（如 Amazon CloudWatch Events 和告警）以及与其他服务 [如 AWS Secrets Manager 和 Amazon Simple Storage Service（Amazon S3）] 的集成。

全局数据库失效转移

在开始托管计划失效转移之前，我们建议执行以下操作以优化应用程序可用性：

  • 在非高峰时段或对主 Aurora 集群的写入量极少的其他时间执行迁移。
  • 使应用程序离线以防止写入发送到 Aurora 全局数据库的主集群。这将减少失效转移时间。
  • 检查 Aurora 全局数据库中的辅助 Aurora 集群的延迟时间。此指标告诉您辅助集群比主集群落后多少时间（以毫秒为单位）。其值与 Aurora 完成失效转移所花的时间成正比。

要对全局数据库进行失效转移，请完成以下步骤：

  1. 在 Databases（数据库）页上，选择全局数据库。
  2. 在 Actions（操作）菜单上，选择 Fail over global database（全局数据库失效转移）。
    此时会出现一个弹出框，要求您确认失效转移。
  3. 选择要失效转移到的辅助 Aurora 集群，然后选择 Fail over global database（全局数据库失效转移）。

失效转移开始后，主 Aurora 集群变为只读。辅助 Aurora 集群担任主集群角色并将其只读节点提升为完全写入状态。当主集群和辅助集群担任新角色时，您的应用程序在短时间内不可用。顶部横幅显示失效转移进度。

失效转移期间，所有连接都会丢失，并且必须重试进行中的事务。

当辅助 Aurora 集群赶上主集群的更改时，失效转移即告完成。您可以在顶部横幅中看到成功通知。

现在，您可以将应用程序配置为使用新主集群的数据库端点。通过选择数据库标识符，可以在 Connectivity & Security（连接和安全）选项卡上找到端点名称。

从全局数据库移除源区域中的 Aurora 集群（可选）

只有在新区域中完成测试并准备好迁移数据库时，才算完成这些步骤。如果您计划在两个区域之外运营，或者希望将源区域保留为灾难恢复选项，则可以跳过本节。

失效转移后，源 Aurora 集群成为辅助集群。完成以下步骤，从全局数据库中移除辅助 Aurora 集群：

  1. 在 Databases（数据库）页面上，选择辅助 Aurora 集群。
  2. 在 Actions（操作）菜单上，选择 Remove from global database（从全局数据库删除）。
  3. 当系统要求确认时，请在弹出框中选择 Remove and promote（移除并提升）。

提升过程所用时间应少于一分钟。

从全局数据库移除目标区域中的 Aurora 集群

失效转移后，目标 Aurora 集群成为主集群。要从全局数据库中移除主集群，请完成以下步骤：

  1. 在 Databases（数据库）页面上，选择主数据库集群（目标区域）。
  2. 在 Actions（操作）菜单上，选择 Remove from global database（从全局数据库删除）。
  3. 当系统要求确认时，请在弹出框中选择 Remove and promote（移除并提升）。

提升过程所用时间应少于一分钟。完成后，主数据库集群的角色将变为 Regional（区域）。这是您的目标 Aurora 集群。

清理未使用的资源

迁移到新区域后，可以删除未使用的资源：

  1. 在 Databases（数据库）页面上，选择源 Aurora 集群中的实例。如果源集群中有其他实例，请重复此过程。
  2. 在 Actions（操作）菜单中，选择 Delete（删除）。
  3. 选择全局数据库，然后在 Actions（操作）菜单上选择 Delete（删除）。

其他考虑因素

使用 Aurora Global Database 进行迁移时还有其他考虑因素：

结论

在这篇文章中，我们展示了如何使用 Aurora Global Database 基于存储的复制功能将 Aurora MySQL 或 PostgreSQL 数据库从一个区域迁移到另一个区域。使用此解决方案时，可以尽量减少所需的工作量和停机时间。因为在存储级别执行复制，它还可限制对数据库性能的影响。

阅读有关如何使用 Aurora 全局数据库和其他使用案例（如灾难恢复）的更多信息。

关于作者

Vineedh George 是一位高级解决方案架构师，帮助组织加快采用基于云的解决方案。

 

 

 

 

Tianxin Li 是 AWS 加拿大的迁移解决方案架构师，常驻多伦多。他帮助客户加快向云迁移的过程。

 

 

 

 

Pratima Bhardwaj 领导 AWS 的解决方案架构师团队。她常驻多伦多。她与各个行业领域的企业客户合作。