使用 Amazon Aurora MySQL 跨账户迁移和二进制日志复制可减少停机时间

在收购、出售或合并操作或重组 亚马逊云科技 账户和组织结构时，将 A mazon Aurora MySQL 兼容版 上的关系数据库 从一个 亚马逊云科技 账户迁移到另一个 亚马逊云科技 账户是常见的用例。这些迁移可能很复杂，对于大型工作负载尤其如此。重要的是要进行适当的规划和实施，以确保成功迁移并减少停机时间。

在这篇文章中，我们将讨论为此类迁移执行初始数据加载的步骤和最佳实践，然后配置二进制日志复制以减少停机时间，以及切换的步骤。尽管本文重点介绍与 Aurora MySQL 兼容的数据库 (DB) 集群从一个 亚马逊云科技 账户向另一个 亚马逊云科技 账户的区域内迁移步骤，但您也可以将此解决方案用于以下用例：

  • 将 Aurora MySQL 迁移到现有 亚马逊云科技 账户 中的另一个 亚马逊虚拟私有云（亚马逊 VPC） 。
  • 将 Aurora MySQL 迁移到相同或不同亚马逊 VPC 中的另一个子网组

解决方案概述

该解决方案包括两个阶段：初始数据加载和持续复制（更改数据捕获）。

阶段 1：初始数据加载

有多个选项可以执行初始数据加载，例如：

  • 数据库克隆：对于 Aurora MySQL，你可以使用 Aurora 克隆 。如果源账户和目标 亚马逊云科技 账户位于同一 亚马逊云科技 区域，则建议使用 Aurora 克隆进行跨账户迁移。
  • 快照恢复： 从 Aurora MySQL 的数据库集群快照中 恢 复。如果源账户和目标 亚马逊云科技 账户位于不同的 亚马逊云科技 区域，则建议使用这种方法进行跨账户迁移。
  • 逻辑恢复：使用本机或第三方数据库迁移方法，例如 mysqldump 或 mydumper/myloader 。

在这篇文章中，我们使用 Aurora 克隆为 Aurora MySQL 数据库集群执行初始数据加载，因为与其他方法相比，这是一种快速且经济实惠的方法。

第 2 阶段：更改数据捕获

您可以使用 MySQL 二进制日志 (binlog) 复制 进行持续复制，同时将 Aurora MySQL 数据库从现有 亚马逊云科技 账户迁移到另一个 亚马逊云科技 账户。通常，这是在同构迁移期间进行持续复制的最简单和推荐的选项。

如果您使用的是 Aurora MySQL 3.03.1 或更高版本 ，则还可以选择设置 增强二进制日志 ，以便在迁移期间 进行持续复制。增强版二进制日志与现有的基于二进制日志的工作负载兼容，您与之交互的方式与社区 MySQL 二进制日志交互的方式相同。

架构概述

在这篇文章中，我们使用 亚马逊云科技 资源访问管理器 (亚马逊云科技 RAM) 与目标 亚马逊云科技 账户共享 Aurora MySQL 数据库集群，并使用 Aurora 克隆进行初始数据加载。我们还使用 MySQL 二进制日志复制来捕获变更数据。

Architecture Overview

为了实现此解决方案，我们完成了以下步骤：

  1. 配置二进制日志
  2. 执行初始数据加载
  3. 在源上创建复制用户
  4. 配置二进制日志复制以捕获变更数据 (CDC)
  5. 监控复制
  6. 执行切换

在本演示中，源 AWS 账户为 6144xxxxxxxx，目标账户为 2634xxxxxxxx 。 源 Aurora MySQL 数据库集群名为 aurora-my sql-source-01，目标集群是 aurora-mysql-target-01 ， 使用 与亚马逊 Aurora MySQL 兼容版本 3（兼容 MySQL 8.0）。

请注意，在您的 亚马逊云科技 账户中启动新资源会产生额外费用。

先决条件

在开始之前，请务必完成以下先决条件：

  • 使用 VPC 对等连接或 亚马逊云科技 Transit Gate w ay 设置源和目标 亚马逊云科技 账户的网络连接。有关更多信息，请参阅 创建 VPC 对等连接 。
  • 一个 Amazon VPC 安全组，其入站规则允许从源到目标的连接。有关更多信息，请参阅 使用安全组 控制资源流量 。
  • 在您的主机上 安装和配置了最新版本 的 亚马逊云科技 CLI ，例如 EC2、Cloud9 或类似实例。

Aurora MySQL

1。设置二进制日志复制

在开始初始数据加载之前，二进制日志复制必须处于活动状态并捕获二进制日志。然后，可以将二进制日志用于持续复制。Aurora MySQL 支持基于行、基于语句和混合二进制日志记录格式。默认情况下，Aurora MySQL 上的二进制日志处于禁用状态，除非要从 Aurora 集群中复制数据，否则无需启用二进制日志。 要启用二进制日志，请在连接到源数据库集群的自定义数据库集群 参数组 中将 binlog_form at 参数设置为 ROW 、 STATEMENT 或 MIXED。 由于 binlog_for mat 是一个静态参数；您必须重新启动集群的写入器数据库实例才能使更改生效。有关启用 Aurora MySQL 二进制日志记录的更多信息，请参阅 配置 Aurora MySQL 二进制日志记录 。

要验证二进制日志的状态，请在源 Aurora MySQL 数据库中使用以下命令： 

source|MySQL[(none)]> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)

您也可以考虑启用增强型二进制日志，以减少开启二进制日志所造成的计算性能开销。为了减少开销，增强型 binlog 将二进制文件和事务日志并行写入存储，从而最大限度地减少在事务提交时写入的数据。增强版二进制日志在 Aurora MySQL 3.03.1 版本（兼容 MySQL 8.0.26）及更高版本上可用。有关更多信息，请参阅 设置增强版 binlog 。如果您使用的是支持的 Aurora MySQL 版本，则在正确配置增强二进制日志后，本文中的其余步骤将保持不变。

2。配置二进制日志保留

在设置持续复制时，我们需要确保主 Aurora MySQL 实例上的二进制日志保留足够长的时间以捕获变更数据。要设置二进制日志保留时间范围，请使用 mys ql.rds_set_config uration 过程并指定二进制 日志保留时数的配置参数 以及在数据库集群上保留二进制日志文件的 小时数。Aurora MySQL 3.x、Aurora MySQL 版本 2.11 及更高版本的最大值为 90 天。 二进制日志保留时 数的默认值 为 NULL 。对于 Aurora MySQ L，空 表示不保留二进制日志。

您应该根据几个关键因素来确定二进制日志保留时长，例如 Aurora MySQL 数据库集群的大小、Aurora 克隆所需的时间以及 Aurora 克隆后的二进制日志复制开始时间。在这篇文章中，您将使用以下代码在 Aurora MySQL 上将二进制日志保留期配置为 3 天： 

source|MySQL[(none)]> CALL mysql.rds_set_configuration('binlog retention hours', 72);
Query OK, 0 rows affected (0.01 sec)
source|MySQL[(none)]> CALL mysql.rds_show_configuration\G
*************************** 1. row ***************************
       name: binlog retention hours
      value: 72
description: binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
1 row in set (0.00 sec)

3。执行初始数据加载

执行 Aurora MySQL 的初始数据加载包括多个步骤，例如使用 亚马逊云科技 资源访问管理器 (亚马逊云科技 RAM) 与其他账户安全共享数据库集群，然后在目标账户中设置 Aurora 克隆。

3.1 允许目标 亚马逊云科技 账户克隆数据库集群

要在目标 亚马逊云科技 账户中创建源 Aurora MySQL 数据库集群的克隆，您需要向目标 亚马逊云科技 账户授予权限。使用 亚马逊云科技 资源访问管理器 (亚马逊云科技 RAM) 设置共享权限，以允许目标 亚马逊云科技 账户克隆源 亚马逊云科技 账户拥有的 Aurora MySQL 数据库集群。有关更多信息，请参阅 亚马逊云科技 RAM 用户指南 中的 共享您拥有的资源 。

在这篇文章中，您使用以下 亚马逊云科技 RAM CLI 命令在源 亚马逊云科技 账户 中创建资源共享 来授予在目标 亚马逊云科技 账户中克隆数据库集群的权限。 

source-aws-account> aws ram create-resource-share --name aurora_share \
--region us-east-1 \
--resource-arns arn:aws:rds:us-east-1:6144xxxxxxxx:cluster:aurora-mysql-source-01 \
--principals 2634xxxxxxxx

接下来， 在目标 亚马逊云科技 账户中使用 亚马逊云科技 RAM CLI 命令 获取资源共享邀请 来查看克隆 Amazon Aurora 集群的待处理邀请。 

target-aws-account> aws ram get-resource-share-invitations --region us-east-1 --query 'resourceShareInvitations[?status==`PENDING`]'
[
    {
        "resourceShareInvitationArn": "arn:aws:ram:us-east-1:6144xxxxx:resource-share-invitation/xxxxxxx",
        "resourceShareName": "aurora_share",
        "resourceShareArn": "arn:aws:ram:us-east-1:6144xxxxx:resource-share/xxxxxxx",
        "senderAccountId": "6144xxxxxxxx",
        "receiverAccountId": "2634xxxxxxxx",
        "invitationTimestamp": "2023-05-06T22:20:49.373000-04:00",
        "status": "PENDING"
    }
]

列出所有待处理的邀请后，在目标 AWS 账户中使用 AWS RAM CLI 命令 accep t-resource-share-share-invitationarn，通过指定 在之前的命令中收到的 ResourceShareInvitationarn 来接受克隆亚马逊 Aurora 集群的 邀请 ： 

target-aws-account> aws ram accept-resource-share-invitation \
--resource-share-invitation-arn arn:aws:ram:us-east-1:6144xxxxxx:resource-share-invitation/xxxxxxx \
--region us-east-1
{
    "resourceShareInvitation": {
        "resourceShareInvitationArn": "arn:aws:ram:us-east-1:6144xxxxxx:resource-share-invitation/xxxxxxx",
        "resourceShareName": "aurora_share",
        "resourceShareArn": "arn:aws:ram:us-east-1: 6144xxxxxx:resource-share/xxxxxxx",
        "senderAccountId": "6144xxxxxx",
        "receiverAccountId": "2634xxxxxx",
        "invitationTimestamp": "2023-05-06T22:39:05.359000-04:00",
        "status": "ACCEPTED"
    }
}

通过将目标账户添加到 KM S 密钥策略，您还将与目标 亚马逊云科技 账户共享用于加密源数据库集群的 亚马逊云科技 密钥管理服务 (亚马逊云科技 KMS) 密钥。有关更新密钥策略的详细信息，请参阅 亚马逊云科技 KMS 开发者指南 中的密 钥策略 。有关创建密钥策略的示例，请参阅 允许访问 亚马逊云科技 KMS 密钥 。您无法创建使用默认 RDS 密钥加密的集群的跨账户克隆。有关更多信息，请参阅 跨账户克隆 的 限制 。

3.2 使用 Aurora 克隆创建目标 Aurora MySQL 数据库集群

成功与目标账户共享 Aurora MySQL 数据库集群后，在目标 亚马逊云科技 账户中创建源数据库集群的 A urora 克隆 。有关更多信息，请参阅 克隆另一个 亚马逊云科技 账户拥有的 Aurora 集群 。

注意： 在克隆过程中，源数据库集群仍然可用于所有事务，不会影响性能。

在这篇文章中，你使用 亚马逊云科技 RDS CLI 命令将数据库 集群恢复到时间点 来克隆目标 Aws 账户中的 Aurora MySQL 数据库集群。 

target-aws-account> aws rds restore-db-cluster-to-point-in-time \
--source-db-cluster-identifier=arn:aws:rds:us-east-1:6144xxxxxx:cluster:aurora-mysql-source-01 \
--db-cluster-identifier=aurora-mysql-target-01 \
--restore-type=copy-on-write \
--use-latest-restorable-time \
--kms-key-id "mrk-b8xxxxxxx" \
--db-cluster-parameter-group-name "aurora-mysql8-custom-db-cluster" \
--vpc-security-group-ids "sg-014xxxxxxx"

将 db-cluster 还原到时间点 AWS CLI 命令仅恢复数据库集群 。使用以下命令检查克隆状态： 

target-aws-account> aws rds describe-db-clusters --db-cluster-identifier aurora-mysql-target-01 \
--query '*[].{Status:Status,Engine:Engine,DBClusterIdentifier:DBClusterIdentifier}' 
[
    {
        "Status": "available",
        "Engine": "aurora-mysql",
        "DBClusterIdentifier": "aurora-mysql-target-01"
    }
]

集群处于 可用 状态后，您可以通过调用 亚马逊云科技 RDS CLI 命令 c reate-db-instance 来创建写入器实例 ，为恢复的数据库集群创建数据库实例，如下所示。在这篇文章中，我们使用实例标识符作为 aurora -mysql-target-01。 

target-aws-account> aws rds create-db-instance \
--db-instance-identifier aurora-mysql-target-01 \
--db-cluster-identifier aurora-mysql-target-01 \
--db-instance-class  db.t3.medium \
--engine aurora-mysql

4。在源数据库上创建复制用户

使用复制 客户端 和复制 从属 权限，在源 Aurora MySQL 数据库上创建仅用于 复制 的用户 ID。 参见以下代码作为示例： 

source|MySQL[(none)]> create user 'repl_user'@'%' IDENTIFIED BY 'xxxxx';
source|MySQL[(none)]> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%';

有关参数的更多详细信息，请参阅 在复制源上 创建复制用户 。

5。配置持续复制

处理二进制日志复制的连接是安全的，因为它们永远不会离开 亚马逊云科技 网络，因为源数据库和目标数据库都位于私有子网中，源账户和目标账户通过 VPC 对等连接进行对等。要启动复制，让我们看看如何检索所需的二进制日志详细信息。

通过在 亚马逊云科技 命令 行接口 ( 亚马逊云科技 CLI) 上调用 desc ribe-event s 命令 来获取二进制日志文件名和位置。以下是带有输出片段的 desc ribe-event s 命令示例： 

target-aws-account>aws rds describe-events --source-identifier aurora-mysql-target-01-instance-01 --source-type "db-instance"
{
    "Events": [
        {
            "SourceIdentifier": "aurora-mysql-target-01",
            "SourceType": "db-instance",
           "Message": "Binlog position from crash recovery is mysql-bin-changelog.000013 77991983",
...]
}

保存二进制日志文件名（在本例中我们使用了 mysql-bin-changelog.000013 和位置 77991983 的值）以开始从源 Aurora MySQL 数据库集群进行复制。 现在，使用写入器终端节点连接到目标 Aurora MySQL 数据库集群，通过调用 mysql.rds_set_external_source 过程（适用于 Aurora MyS QL 版本 3）或 mysql.rds_set_external_master 程序（适用于 Aurora MySQL 版本 2），开始从源 Aurora MySQL 进行复制。 有关设置复制的更多详细信息，请参阅在 副本目标上 启用复制 。

在这篇文章中，我们使用以下方法来配置和启动复制： 

target|MySQL[(none)]> call mysql.rds_set_external_source(
'aurora-mysql-source-01.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com',
3306,
'repl_user',
'<password>',
'mysql-bin-changelog.000013', 77991983, 
0);
target|MySQL[(none)]> CALL mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.03 sec)

从 Aurora MySQL 版本 3 开始，不再使用二进制日志复制来复制数据控制语言 (DCL) 语句，例如 CREATE USER、GRANT 和 REVOKE。如果您计划在复制过程中运行任何 DCL 语句，则需要在源数据库和目标数据库上运行 DCL 语句。

6。监控复制

要监控目标数据库落后于源数据库的距离，请连接到目标数据库实例并运行 显示副本状态 （Aurora MySQL 版本 3）或 显示从属状态 （Aurora MySQL 版本 2）。在以下命令输出中， Seconds_Behind_Source 字段告诉您目标数据库实例落后于源 数据库实例的距离： 

target|MySQL[(none)]> show replica status\G
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: aurora-mysql-source-01.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com
Source_User: repl_user
Source_Port: 3306
Seconds_Behind_Source: 0
........
1 row in set (0.00 sec)

7。执行切换

副本延迟值接近零后，您就可以进行直接转换，将应用程序指向目标账户中的 Aurora MySQL 数据库集群。我们建议您在低流量时段规划切换，并遵循内部业务切换清单和流程。以下是转换过程的关键步骤：

  1. 停止接受源数据库上的连接。您可以通过删除允许连接的入站规则来更新与源关联的 VPC 安全组。
  2. 确保从源数据库实例到目标数据库实例的复制延迟为 0。
  3. 调用 mysql. rds_stop_replication 过程停止二进制日志复制。 
target|MySQL [(none)]> CALL mysql.rds_stop_replication;
+---------------------------+
| Message |
+---------------------------+
| Replica is down or disabled |
+---------------------------+
1 row in set (1.05 sec)
  1. 使用目标数据库端点更新应用程序配置或 DNS CNAME 记录。
  2. 在使用新目标启动应用程序之前，您还可以使用二进制日志复制设置从目标账户中的新 Aurora MySQL 集群向旧集群的复制，以满足备用要求。
  3. 使用目标 Aurora MySQL 数据库启动应用程序。

清理

成功转换并将应用程序连接到目标账户中的 Aurora MySQL 集群后，您可以决定暂时停止或删除源 Aurora MySQL 集群。有关停止 Aurora 集群的更多信息，请参阅 停止 Aurora 数据库集群 ；有关删除 Aurora 集群的更多信息，请参阅 删除 Aurora 数据库集群和数据库实例 。

结论

在这篇文章中，我们讨论了将您的 Aurora MySQL 集群从一个 亚马逊云科技 账户迁移到另一个 亚马逊云科技 账户所涉及的各种步骤，同时设置二进制日志复制以减少停机时间。鉴于数据库迁移涉及的复杂性，我们强烈建议在生产环境中进行更改之前，先在非生产环境中测试迁移步骤。如果您计划使用 亚马逊云科技 数据库迁移服务 (亚马逊云科技 DMS) 进行 Aurora M ySQL 迁移，请查看在 尽可能减少停机时间的情况下 执行跨账户 Amazon Aurora MySQL 迁移 中提供的步骤。

作者简介

Alok Srivastava 是亚马逊网络服务的高级数据库顾问。在客户和合作伙伴迈向 亚马逊云科技 云的过程中，他与他们合作，重点是数据库迁移和现代化计划。

Shagun Arora 是亚马逊网络服务的数据库专家解决方案架构师。她与客户合作，在 亚马逊云科技 云中设计可扩展、高度可用和安全的解决方案。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。