MySQL 迁移方案概览

MySQL 迁移实战

注意事项

技巧

总结

?

一、为什么要迁移

MySQL 迁移是 DBA 日常维护中的一个工作。迁移，是把实际存在的物体挪走，保证该物体的完整性以及延续性。

?

生产环境中，有以下情况需要做迁移：

?

1、磁盘空间不够。比如一些老项目，选用的机型并不一定适用于 数据库。随着时间的推移，硬盘很有可能出现短缺；

2、业务出现瓶颈。比如项目中采用单机承担所有的读写业务，业务压力增大，不堪重负。如果 IO 压力在可接受的范围，会采用读写分离方案；

3、机器出现瓶颈。机器出现瓶颈主要在磁盘 IO 能力、内存、CPU，此时除了针对瓶颈做一些优化以外，选择迁移是不错的方案；

4、项目改造。某些项目的数据库存在跨机房的情况，可能会在不同机房中增加节点，或者把机器从一个机房迁移到另一个机房。再比如，不同业务共用同一台服务器，为了缓解服务器压力以及方便维护，也会做迁移。

一句话，迁移工作是不得已而为之。实施迁移工作，目的是让业务平稳持续地运行。

?

二、MySQL 迁移方案概览

MySQL 迁移就是在保证业务平稳持续地运行的前提下做备份恢复。那问题就在怎么快速安全地进行备份恢复。

?

首先，备份。针对每个主节点的从节点或者备节点，都有备份。这个备份可能是全备，可能是增量备份。在线备份的方法，可能使用 mysqldump（MySQL 用于转存储数据库的实用程序。它主要产生一个SQL脚本，其中包含从头重新创建数据库所必需的命令），xtrabackup（是一个对 InnoDB 做数据备份的工具，支持在线热备份，是商业备份工具 InnoDB Hotbackup 的一个很好的替代品），mydumper（是一个针对MySQL和Drizzle的高性能多线程备份和恢复工具）等。

?

针对小容量（10GB 以下）的备份，可以使用 mysqldump。但对大容量数据库（GB 或者 TB 级别），mysqldump 就不合适，会产生锁，耗时太长。

此时，可以选择 xtrabackup 或者直接拷贝数据目录。直接拷贝数据目录方法，不同机器传输可以使用 rsync，耗时跟网络相关。使用 xtrabackup，耗时主要在备份和网络传输。如果有全备或者指定库的备份文件，这是获取备份的最好方法。如果备库可以容许停止服务，直接拷贝数据目录是最快的方法。如果备库不允许停止服务，我们可以使用 xtrabackup（不会锁定 InnoDB 表），这是完成备份的最佳折中办法。

其次，恢复。针对小容量（10GB 以下）数据库的备份文件，我们可以直接导入。针对大容量数据库（GB 或者 TB 级别）的恢复，拿到备份文件到本机以后，恢复不算困难。具体的恢复方法可以参考第三节。

?

三、MySQL 迁移实战

上面试为什么要做迁移，以及迁移需要做什么，接下来是在生产环境如何操作。不同的应用场景，有不同的解决方案。

?

假设有如下约定：

?

1、为了保护隐私，本文中的服务器 IP 等信息经过处理；

2、如果服务器在同一机房，用服务器 IP 的 D 段代替服务器，具体的 IP 请参考架构图；

3、如果服务器在不同机房，用服务器 IP 的 C 段 和 D 段代替服务器，具体的 IP 请参考架构图；

4、每个场景给出方法，但不会详细地给出每一步执行什么命令，因为一方面，这会导致文章过长；另一方面，我认为只要知道方法，具体的做法就会迎面扑来的，只取决于掌握知识的程度和获取信息的能力；

5、实战过程中的注意事项请参考第四节。

3.1，场景一：主一从结构迁移从库

我们从简单的结构入手。A 项目，原本是一主一从结构。101 是主节点，102 是从节点。因业务需要，把 102 从节点迁移至 103，架构图如图 1。102 从节点的数据容量过大，不能使用 mysqldump 的形式备份。和研发沟通后，形成一致的方案。

?

下面是 A 项目 MySQL 架构图。

?

?

具体做法是这样：

?

1、研发将 102 的读业务切到主库；

?

2、确认 102 MySQL 状态（主要看 PROCESS LIST），观察机器流量，确认无误后，停止 102 从节点的服务；

?

3、103 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份；

?

4、将 102 的整个 mysql 数据目录使用 rsync 拷贝到 103；

?

5、拷贝的同时，在 101 授权，使 103 有拉取 binlog 的权限（REPLICATION SLAVE, REPLICATION CLIENT）；

?

6、待拷贝完成，修改 103 配置文件中的 server_id，注意不要和 102 上的一致；

?

7、在 103 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；

?

8、进入 103 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；

?

9、Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 101 和 103 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；

?

10、和研发沟通，除了做数据一致性验证外，还需要验证账号权限，以防业务迁回后访问出错；

?

11、做完上述步骤，可以和研发协调，把 101 的部分读业务切到 103，观察业务状态；

?

12、如果业务没有问题，证明迁移成功。

?

3.2，场景二：主一从结构迁移指定库

我们知道一主一从只迁移从库怎么做之后，接下来看看怎样同时迁移主从节点。因不同业务同时访问同一服务器，导致单个库压力过大，还不便管理。于是，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点，架构图如图二。此次迁移只需要迁移指定库，这些库容量不是太大，并且可以保证数据不是实时的。

?

下图是 B 项目 MySQL 架构图。

?

?

具体的做法如下：

?

1、103 和 104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；

?

2、102 导出数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；

?

3、102 收集指定库需要的账号以及权限；

?

4、102 导出数据完毕，使用 rsync 传输到 103，必要时做压缩操作；

?

5、103 导入数据，此时数据会自动同步到 104，监控服务器状态以及 MySQL 状态；

?

6、103 导入完成，104 同步完成，103 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；

?

7、上述完成后，可研发协作，将 101 和 102 的业务迁移到 103 和 104，观察业务状态；

?

8、如果业务没有问题，证明迁移成功。

?

3.3，场景三：主一从结构双边迁移指定库