自建 MySQL 数据库迁移工具及具体操作

发布于: Nov 30, 2022

【概要】MySQL 数据库迁移工具在自建 mysql 数据库的迁移中起到至关重要的作用，与基于Amazon MySQL RDS 的数据库迁移不同，自建数据库的迁移步骤更为繁琐，本文将会为您介绍几种场景的迁移及方式。

MySQL 数据库迁移工具在自建 mysql 数据库的迁移中起到至关重要的作用，与基于 Amazon MySQL RDS 的数据库迁移不同，自建数据库的迁移步骤更为繁琐，本文将会为您介绍几种场景的迁移及方式。

场景三：自建 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，如果是在本地数据中心生成的备份，并且尺寸特别大的话，可以使用 Amazon 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：通过使用 Amazon DMS 服务完成迁移，整个流程如下所示：

Amazon Database Migration Service（DMS）服务可以帮助客户在最小停机时间的情况下，采用在源库上捕获变化数据，并在目标库上应用变化数据的形式，进行数据库的整体迁移。DMS 不仅可以进行相同数据库引擎的迁移，同时还支持不同数据库引擎之间的迁移。不过 DMS 只能迁移数据本身，其他数据库对象，比如存储过程等，是不能迁移的。需要手工在目标数据库里创建。具体操作过程如下所示：

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

在 DMS 的主页上，选择 Replication instances，然后在右边点击 Create replication instance 按钮。在显示的界面上输入 DMS 实例相关的一些信息，比如实例名称，实例大小等。需要注意的是，如果需要传输的数据量比较大，同时源数据库上有较大的工作压力的话，应该选择较大的机型。

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 里，如下图所示：