各种场景下从 MySQL 数据库迁移到 Amazon Aurora

随着 Amazon Aurora 数据库被客户从认识到认可，越来越多的企业客户在完成功能和性能的验证以后，会考虑把他们在生产环境中运行的 MySQL 数据库迁移到 Amazon Aurora 数据库上。本文描述了在各种不同的场景下，如何把 MySQL 数据库的数据迁移到 Amazon Aurora 里。以下内容的描述，如果没有特别说明，都是基于 AWS 的 us-west-2 区进行介绍，并且按照从简单到复杂的顺序对各种场景进行描述。

场景一：Amazon MySQL RDS 迁移到 Amazon Aurora 并有停机时间

如果客户正在使用 Amazon MySQL RDS，并且有足够的停机迁移的时间窗口的话，那么可以通过 RDS 快照的方式进行迁移。具体操作过程如下：

1）停止应用程序对源数据库的写入操作。

2）对源数据库创建快照，可以使用图形界面进行操作，选中要迁移的数据库实例，Actions 下来菜单中选择 Take snapshot，如下图所示：

3）根据快照恢复出一个 Aurora 数据库。可以使用图形界面操作，在数据库列表中，选中之前创建快照的数据库实例，Actions 下来列表中选择 Migrate snapshot，如下图所示。

在随后显示的页面中，输入 Aurora 数据库的相关信息即可，包括指定一个新的 Aurora 数据库实例名称，网络配置等，这部分内容与直接创建一个新的 Aurora 数据库是完全一致的。

4）等到 Aurora 数据库创建好以后，就可以修改应用程序的连接字符串，指向 Aurora，从而投入使用了。

场景二：Amazon MySQL RDS 迁移到 Amazon Aurora 并要求最小停机时间

如果客户正在使用 Amazon MySQL RDS，并且没有足够的停机时间来通过 snapshot 的方式进行迁移的话，那么可以通过为 MySQL RDS 创建 Aurora 读副本的方式进行迁移。具体操作过程如下：

1）在控制台界面上选中要迁移的 MySQL RDS 数据库，在 Actions 下拉菜单中选择 Create Aurora read replica，如下图所示。

2）在创建 Aurora 副本的界面上输入相关的信息，其过程与创建一个新的 Aurora 数据库类似。

在创建 Aurora 读副本的过程中，源 MySQL RDS 数据库可以仍然被业务系统访问并使用。在读副本创建完毕以后，该副本的内容会自动与 MySQL RDS 主库保持数据同步。

在确定要进行切换之前（通常都是在业务低谷的时间段），关闭应用程序，从而停止应用程序对主库的写入操作，并登陆到 Aurora 里执行下面的命令来判断 Aurora 读副本是否与主库保持同步了：

show slave status \G

检查输出里的 Seconds_Behind_Master 字段的值，如果为 0 则表示 Aurora 读副本已经与 MySQL RDS 主库保持同步了。否则继续等待，直到该字段为 0 为止。然后选择 Aurora 只读副本，在 Actions 下拉菜单中选择 Promote 选项。

在弹出的界面中，选择 Promote Read Replica 按钮，从而把 Aurora 只读副本提升为主库。

一旦完成主从切换，再次登陆到 Aurora 数据库，执行 show slave status 的时候，会发现已经没有输出信息了。这也就说明 Aurora 数据库已经不再是一个只读副本，而变成了一个完全独立的数据库。

修改应用程序的数据库连接字符串，使其指向 Aurora 数据库，并启动应用程序，从而开始在生产环境中使用 Aurora 数据库。

场景三：自建 MySQL 数据库迁移到 Amazon Aurora 并有足够的停机时间

如果客户没有使用 Amazon MySQL RDS，而是在 EC2 虚拟机里，或者本地数据中心的服务器上，由客户自己部署安装的 MySQL 数据库，需要迁移到 Aurora 数据库，同时也有足够的停机迁移时间窗口，那么可以使用备份恢复的方式，进行迁移。其操作过程如下：

1）到 Percona 官方网站上下载 XtraBackup 工具，这里下载 4.1 版本（https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/），如下所示：

wget https://www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.1/binary/tarball/percona-xtrabackup-2.4.1-Linux-x86_64.tar.gz

tar -xzvf percona-xtrabackup-2.4.1-Linux-x86_64.tar.gz

2）执行 Percona XtraBackup 命令，创建备份。比如下面的例子：

innobackupex –user=root –password= –database=myaurora –stream=tar ~/s3-restore/backup2 | split -d –bytes=51200000 – ~/s3-restore/backup.tar

3）把数据库备份（本例中是 tar 开头的文件，比如 backup.tar00，其中包含了 xtrabackup 生成的数据库备份文件）上传到 S3，如果是在本地数据中心生成的备份，并且尺寸特别大的话，可以使用 AWS Snowball 服务进行上传。具体参考：https://aws.amazon.com/cn/snowball/

4）把备份从 S3 恢复到 Amazon Aurora 数据库里。如下图所示：

a.在 RDS 控制台上选择 Restore from S3 按钮

b.选择 Aurora 引擎

c.指定备份的相关信息，如下图所示

d.在数据库的配置的相关页面上，输入 Aurora 数据库的信息，比如数据库的名称，管理员名称与密码等，这一步与正常创建 Aurora 数据库的过程是一样的。

5）当 Aurora 数据库恢复完成以后，就可以投入生产使用了。

场景四：自建 MySQL 数据库迁移到 Amazon Aurora 并要求最小停机时间

如果客户是在 EC2 或者本地数据中心自己部署的 MySQL 数据库，希望迁移到 Amazon Aurora 数据库，同时没有足够的停机时间来通过备份恢复的方式完成整个迁移。这种场景相对比较复杂，通常可以使用两种方式来进行最小时间停机的迁移。

方式 1：通过构建 MySQL 主从副本的方式完成迁移，整个流程如下所示：

1）创建 Aurora 从库（即读副本），通过 binlog 与 MySQL 主库保持同步，如下图所示。

2）MySQL 主，Aurora 从的关系建立起来以后，持续进行数据同步，如下图所示。在这个阶段，Aurora 数据库只能进行读操作，不能进行写操作，可以把 Aurora 的 read_only 参数设置为 1 强制只读，或者也可以保持 0，而是从应用程序端进行控制，禁止其在 Aurora 数据库里进行写操作。

3）当需要进行切换的时候，也就是业务低谷的时候，停止应用程序在源 MySQL 数据库里的写入操作，然后等到 Aurora 从库的数据与 MySQL 主库的数据完全一致以后，修改应用程序的连接字符串，使其指向 Aurora 从库，使得 Aurora 数据库变为主要的写入数据库（如果你之前把 Aurora 数据库的 read_only 设置为了 1，则需要把其改回到 0，从而允许写入 Aurora 数据库）。而原来的 MySQL 数据库则可以被销毁。该阶段如下图所示。

具体操作过程如下：

1）使用 xtrabackup 对主库进行备份，并指定–slave-info，从而生成日志点的位置信息，如下例所示：

innobackupex –user=root –password= –database=myaurora –slave-info –stream=tar ~/s3-restore/backup2 | split -d –bytes=51200000 – ~/backup.tar

2）提取 tar 开头的文件（比如 backup.tar00）里的 xtrabackup_binlog_info 文件，其中存放了日志点的信息。

3）把备份（这里是 tar 开头的文件，比如 backup.tar00）上传到 S3，并按照场景三所示的方式恢复出一个 Aurora 数据库。

4）进入 Aurora 数据库，并执行下面的存储过程，从而把 Aurora 数据库配置为 MySQL 的副本。注意这里的 mysql-bin.000001 和 1024 就是从 xtrabackup_binlog_info 文件中找出来的、备份的时候的日志点的信息。

CALL mysql.rds_stop_replication;
CALL mysql.rds_set_external_master (
'172.31.20.125'
,'3306'
, 'repadmin'
, '<password>'
, 'mysql-bin.000001'
, '1024'
, 0
);
CALL mysql.rds_start_replication;

5）一旦 Aurora 数据库与主库建立起了主从复制的关系以后，等到业务低谷的时候，停止应用程序对 MySQL 数据库的写入操作，并等到 Aurora 与 MySQL 完全一致以后，把应用程序的数据库连接字符串改为 Aurora 数据库即可。

方式 2：通过使用 AWS DMS 服务完成迁移，整个流程如下所示：

AWS Database Migration Service（DMS）服务可以帮助客户在最小停机时间的情况下， 采用在源库上捕获变化数据，并在目标库上应用变化数据的形式，进行数据库的整体迁移。DMS 不仅可以进行相同数据库引擎的迁移，同时还支持不同数据库引擎之间的迁移。不过 DMS 只能迁移数据本身，其他数据库对象，比如存储过程等，是不能迁移的。需要手工在目标数据库里创建。有关 DMS 的详细信息可以参考：https://aws.amazon.com/dms/。

具体操作过程如下所示：

1）创建复制实例。复制实例的目的在于管理 DMS 在运行复制过程中的一些元数据。创建过程如下图所示。

在 DMS 的主页上，选择 Replication instances，然后在右边点击 Create replication instance 按钮。在显示的界面上输入 DMS 实例相关的一些信息，比如实例名称，实例大小等。需要注意的是，如果需要传输的数据量比较大，同时源数据库上有较大的工作压力的话，应该选择较大的机型。具体细节可以参考：https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html#CHAP_ReplicationInstance.Creating

2）创建 source endpoint，指向源数据库。

在右边选择 Endpoints，点击 Create endpoint 按钮。

选择 endpoint type 为 Source endpoint，并指定源数据库的信息，如下所示：

点击创建 endpoint 按钮从而创建 source endpoint。

创建了 source endpoint 以后，我们可以进行连接测试：

3）创建 target endpoint，指向目标数据库。

先创建一个空的、不包含业务数据的 Aurora 数据库作为目标库，然后创建一个类型为 target endpoint、并指向该 Aurora 数据库的 endpoint。

当 target endpoint 创建完毕以后，我们可以进行连接测试：

4）创建 task，启动复制任务。

创建了源和目标 endpoint 以后，可以开始创建复制任务。选择 Database migration tasks 链接，然后选择 Create task 按钮。

在创建任务的界面上，选择之前创建的 source endpoint 和 target endpoint，migration type 选择 Migrating existing data and replicate ongoing changes，同时选择 Enable CloudWatch logs 复选框。在 Selection rules 部分，我们指定把 MySQL 里的 myaurora 数据库的数据复制到 Aurora 里，如下图所示：

参考https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html 文档了解其他选项的含义。在设置好参数以后，点击 Create task 按钮。

等到任务正常运行以后，则源 MySQL 数据库和目标 Aurora 数据库之间就通过 DMS 服务进行数据同步，并且该同步过程是同步增量数据。如下图所示：

当需要进行数据库切换的时候，通常都是业务低谷的时间段：

停止应用程序向 MySQL 数据库写入数据。

等到所有数据都同步到 Aurora 以后，停止 DMS 任务。

修改应用程序的连接字符串，使其指向 Aurora 数据库，则可以完成整个迁移过程。

使用 AWS DMS 把自建的 MySQL 数据库迁移到 Aurora 数据库的最大好处，在于整个操作过程非常简单，没有太多的步骤，也就不容易出错。在进行 DMS 迁移的过程中，参考如下的建议：

如果要迁移的数据库很大，则建议使用较大的机型作为复制实例

把小的表集中作为一个任务进行复制。而把每个较大的表作为一个单独的任务进行复制。

##结论

本文按照从简单到复杂的顺序，详细描述了各种场景下，MySQL 数据库如何迁移到 Amazon Aurora 数据库上。客户可以根据自己的实际场景，选择自己最适合的方式进行数据库的迁移。

作者介绍：

韩思捷

亚马逊 AWS 解决方案架构师，曾负责大企业客户在 AWS 上的售后技术支持工作，目前负责基于 AWS 的云计算方案架构咨询和设计。在加入 AWS 之前，在中国医药集团，Oracle 以及 EMC 研发中心工作，有多年开发和运维经验，并对各种数据库以及存储应用的高可用架构，方案及性能调优有深入研究。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/every-scene-mysql-database-move-to-amazon-aurora/