一、为什么要迁移
　　MySQL 迁移是 DBA 日常维护中的一个工作。迁移，究其本义，无非是把实际存在的物体挪走，保证该物体的完整性以及延续性。像柔软的沙滩上，两个天真无邪的小孩，把一堆沙子挪向其他地方，铸内心神往的城堡。
　　生产环境中，有以下情况需要做迁移工作，如下：
　　磁盘空间不够。比如一些老项目，选用的机型并不一定适用于数据库。随着时间的推移，硬盘很有可能出现短缺；
　　业务出现瓶颈。比如项目中采用单机承担所有的读写业务，业务压力增大，不堪重负。如果 IO 压力在可接受的范围，会采用读写分离方案；
　　机器出现瓶颈。机器出现瓶颈主要在磁盘 IO 能力、内存、CPU，此时除了针对瓶颈做一些优化以外，选择迁移是不错的方案；
　　项目改造。某些项目的数据库存在跨机房的情况，可能会在不同机房中增加节点，或者把机器从一个机房迁移到另一个机房。再比如，不同业务共用同一台服务器，为了缓解服务器压力以及方便维护，也会做迁移。
　　一句话，迁移工作是不得已而为之。实施迁移工作，目的是让业务平稳持续地运行。
　　二、MySQL 迁移方案概览
　　MySQL 迁移无非是围绕着数据做工作，再继续延伸，无非是在保证业务平稳持续地运行的前提下做备份恢复。那问题在怎么快速安全地进行备份恢复。
　　一方面，备份。针对每个主节点的从节点或者备节点，都有备份。这个备份可能是全备，可能是增量备份。在线备份的方法，可能是使用 mysqldump，可能是 xtrabackup，还可能是 mydumper。针对小容量（10GB 以下）数据库的备份，我们可以使用 mysqldump。但针对大容量数据库（数百GB 或者 TB 级别），我们不能使用 mysqldump 备份，一方面，会产生锁；另一方面，耗时太长。这种情况，可以选择 xtrabackup 或者直接拷贝数据目录。直接拷贝数据目录方法，不同机器传输可以使用 rsync，耗时跟网络相关。使用 xtrabackup，耗时主要在备份和网络传输。如果有全备或者指定库的备份文件，这是获取备份的好方法。如果备库可以容许停止服务，直接拷贝数据目录是快的方法。如果备库不允许停止服务，我们可以使用 xtrabackup（不会锁定 InnoDB 表），这是完成备份的佳折中办法。
　　另一方面，恢复。针对小容量（10GB 以下）数据库的备份文件，我们可以直接导入。针对大容量数据库（数百GB 或者 TB 级别）的恢复，拿到备份文件到本机以后，恢复不算困难。具体的恢复方法可以参考第四节。
　　三、MySQL 迁移实战
　　我们搞明白为什么要做迁移，以及迁移怎么做以后，接下来看看生产环境是怎样操作的。不同的应用场景，有不同的解决方案。
　　阅读具体的实战之前，假设和读者有如下约定：
　　为了保护隐私，本文中的服务器 IP 等信息经过处理；
　　如果服务器在同一机房，用服务器 IP 的 D 段代替服务器，具体的 IP 请参考架构图；
　　如果服务器在不同机房，用服务器 IP 的 C 段 和 D 段代替服务器，具体的 IP 请参考架构图；
　　每个场景给出方法，但不会详细地给出每一步执行什么命令，因为一方面，这会导致文章过长；另一方面，我认为只要知道方法，具体的做法会迎面扑来的，只取决于掌握知识的程度和获取信息的能力；
　　实战过程中的注意事项请参考第五节。
　　3.1 场景一 一主一从结构迁移从库
　　遵循从易到难的思路，我们从简单的结构入手。A 项目，原本是一主一从结构。101 是主节点，102 是从节点。因业务需要，把 102 从节点迁移至 103，架构图如图一。102 从节点的数据容量过大，不能使用 mysqldump 的形式备份。和研发沟通后，形成一致的方案。


　　图一 一主一从结构迁移从库架构图

　　具体做法是这样：
　　研发将 102 的读业务切到主库；
　　确认 102 MySQL 状态（主要看 PROCESS LIST），观察机器流量，确认无误后，停止 102 从节点的服务；
　　103 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份；
　　将 102 的整个 mysql 数据目录使用 rsync 拷贝到 103；
　　拷贝的同时，在 101 授权，使 103 有拉取 binlog 的权限（REPLICATION SLAVE， REPLICATION CLIENT）；
　　待拷贝完成，修改 103 配置文件中的 server_id，注意不要和 102 上的一致；
　　在 103 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
　　进入 103 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
　　Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 101 和 103 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
　　和研发沟通，除了做数据一致性验证外，还需要验证账号权限，以防业务迁回后访问出错；
　　做完上述步骤，可以和研发协调，把 101 的部分读业务切到 103，观察业务状态；
　　如果业务没有问题，证明迁移成功。
　　3.2 场景二 一主一从结构迁移指定库
　　我们知道一主一从只迁移从库怎么做之后，接下来看看怎样同时迁移主从节点。因不同业务同时访问同一服务器，导致单个库压力过大，还不便管理。于是，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点，架构图如图二。此次迁移只需要迁移指定库，这些库容量不是太大，并且可以保证数据不是实时的。


　　图二 一主一从结构迁移指定库架构图

　　具体的做法如下：
　　103 和 104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
　　102 导出数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
　　102 收集指定库需要的账号以及权限；
　　102 导出数据完毕，使用 rsync 传输到 103，必要时做压缩操作；
　　103 导入数据，此时数据会自动同步到 104，监控服务器状态以及 MySQL 状态；
　　103 导入完成，104 同步完成，103 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
　　上述完成后，可研发协作，将 101 和 102 的业务迁移到 103 和 104，观察业务状态；
　　如果业务没有问题，证明迁移成功。
　　3.3 场景三 一主一从结构双边迁移指定库
　　接下来看看一主一从结构双边迁移指定库怎么做。同样是因为业务共用，导致服务器压力大，管理混乱。于是，打算将主节点 101 和从节点 102 同时迁移至新的机器 103、104、105、106，103 充当 104 的主节点，104 充当 103 的从节点，105 充当 106 的主节点，106 充当 105 的从节点，架构图如图三。此次迁移只需要迁移指定库，这些库容量不是太大，并且可以保证数据不是实时的。我们可以看到，此次迁移和场景二很类似，无非做了两次迁移。


　　图三 一主一从结构双边迁移指定库架构图

　　具体的做法如下：
　　103 和 104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
　　102 导出 103 需要的指定库数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
　　102 收集 103 需要的指定库需要的账号以及权限；
　　102 导出103 需要的指定库数据完毕，使用 rsync 传输到 103，必要时做压缩操作；
　　103 导入数据，此时数据会自动同步到 104，监控服务器状态以及 MySQL 状态；
　　103 导入完成，104 同步完成，103 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
　　上述完成后，和研发协作，将 101 和 102 的业务迁移到 103 和 104，观察业务状态；
　　105 和 106 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
　　102 导出 105 需要的指定库数据，正确的做法是配置定时任务，在业务低峰做导出操作，此处选择的是 mysqldump；
　　102 收集 105 需要的指定库需要的账号以及权限；
　　102 导出 105 需要的指定库数据完毕，使用 rsync 传输到 105，必要时做压缩操作；
　　105 导入数据，此时数据会自动同步到 106，监控服务器状态以及 MySQL 状态；
　　105 导入完成，106 同步完成，105 根据 102 收集的账号授权，完成后，通知研发检查数据以及账户权限；
　　上述完成后，和研发协作，将 101 和 102 的业务迁移到 105 和 106，观察业务状态；
　　如果所有业务没有问题，证明迁移成功。
　　3.4 场景四 一主一从结构完整迁移主从
　　接下来看看一主一从结构完整迁移主从怎么做。和场景二类似，不过此处是迁移所有库。因 101 主节点 IO 出现瓶颈，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点。迁移完成后，以前的主节点和从节点废弃，架构图如图四。此次迁移是全库迁移，容量大，并且需要保证实时。这次的迁移比较特殊，因为采取的策略是先替换新的从库，再替换新的主库。所以做法稍微复杂些。


　　图四 一主一从结构完整迁移主从架构图