不同场景下 MySQL 的迁移方案

　　具体的做法是这样：
　　研发将 102 的读业务切到主库；
　　确认 102 MySQL 状态（主要看 PROCESS LIST，MASTER STATUS），观察机器流量，确认无误后，停止 102 从节点的服务；
　　104 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份，注意，此处操作的是 104，也是未来的从库；
　　将 102 的整个 mysql 数据目录使用 rsync 拷贝到 104；
　　拷贝的同时，在 101 授权，使 104 有拉取 binlog 的权限（REPLICATION SLAVE， REPLICATION CLIENT）；
　　待拷贝完成，修改 104 配置文件中的 server_id，注意不要和 102 上的一致；
　　在 104 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
　　进入 104 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
　　Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 101 和 104 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
　　除了做数据一致性验证外，还需要验证账号权限，以防业务迁走后访问出错；
　　和研发协作，将之前 102 从节点的读业务切到 104；
　　利用 102 的数据，将 103 变为 101 的从节点，方法同上；
　　接下来到了关键的地方了，我们需要把 104 变成 103 的从库；
　　104 STOP SLAVE；
　　103 STOP SLAVE IO_THREAD;
　　103 STOP SLAVE SQL_THREAD，记住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
　　104 START SLAVE UNTIL 到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS；
　　104 再次 STOP SLAVE；
　　104 RESET SLAVE ALL 清除从库配置信息；
　　103 SHOW MASTER STATUS，记住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
　　103 授权给 104 访问 binlog 的权限；
　　104 CHANGE MASTER TO 103；
　　104 重启 MySQL，因为 RESET SLAVE ALL 后，查看 SLAVE STATUS，Master_Server_Id 仍然为 101，而不是 103；
　　104 MySQL 重启后，SLAVE 回自动重启，此时查看 IO_THREAD 和 SQL_THREAD 是否为 YES；
　　103 START SLAVE；
　　此时查看 103 和 104 的状态，可以发现，以前 104 是 101 的从节点，如今变成 103 的从节点了。
　　业务迁移之前，断掉 103 和 101 的同步关系；
　　做完上述步骤，可以和研发协调，把 101 的读写业务切回 102，读业务切到 104。需要注意的是，此时 101 和 103 均可以写，需要保证 101 在没有写入的情况下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 锁住 101，然后业务切到 103。注意，一定要业务低峰执行，切记；
　　切换完成后，观察业务状态；
　　如果业务没有问题，证明迁移成功。
　　3.5 场景五 双主结构跨机房迁移
　　接下来看看双主结构跨机房迁移怎么做。某项目出于容灾考虑，使用了跨机房，采用了双主结构，双边均可以写。因为磁盘空间问题，需要对 A 地的机器进行替换。打算将主节点 1.101 和从节点 1.102 同时迁移至新的机器 1.103 和 1.104，1.103 充当主节点，1.104 充当从节点。B 地的 2.101 和 2.102 保持不变，但迁移完成后，1.103 和 2.101 互为双主。架构图如图五。因为是双主结构，两边同时写，如果要替换主节点，单方必须有节点停止服务。

　　图五 双主结构跨机房迁移架构图

　　具体的做法如下：
　　1.103 和 1.104 新建实例，搭建主从关系，此时的主节点和从节点处于空载；
　　确认 1.102 MySQL 状态（主要看 PROCESS LIST），注意观察 MASTER STATUS 不再变化。观察机器流量，确认无误后，停止 1.102 从节点的服务；
　　1.103 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份；
　　将 1.102 的整个 mysql 数据目录使用 rsync 拷贝到 1.103；
　　拷贝的同时，在 1.101 授权，使 1.103 有拉取 binlog 的权限（REPLICATION SLAVE， REPLICATION CLIENT）；
　　待拷贝完成，修改 1.103 配置文件中的 server_id，注意不要和 1.102 上的一致；
　　在 1.103 启动 MySQL 实例，注意配置文件中的数据文件路径以及数据目录的权限；
　　进入 1.103 MySQL 实例，使用 SHOW SLAVE STATUS 检查从库状态，可以看到 Seconds_Behind_Master 在递减；
　　Seconds_Behind_Master 变为 0 后，表示同步完成，此时可以用 pt-table-checksum 检查 1.101 和 1.103 的数据一致，但比较耗时，而且对主节点有影响，可以和开发一起进行数据一致性的验证；
　　我们使用相同的办法，使 1.104 变成 1.103 的从库；
　　和研发沟通，除了做数据一致性验证外，还需要验证账号权限，以防业务迁走后访问出错；
　　此时，我们要做的是将 1.103 变成 2.101 的从库，具体的做法可以参考场景四；
　　需要注意的是，1.103 的单双号配置需要和 1.101 一致；
　　做完上述步骤，可以和研发协调，把 1.101 的读写业务切到 1.103，把 1.102 的读业务切到 1.104。观察业务状态；
　　如果业务没有问题，证明迁移成功。
　　3.6 场景六 多实例跨机房迁移
　　接下来我们看看多实例跨机房迁移证明做。每台机器的实例关系，我们可以参考图六。此次迁移的目的是为了做数据修复。在 2.117 上建立 7938 和 7939 实例，替换之前数据异常的实例。因为业务的原因，某些库只在 A 地写，某些库只在 B 地写，所以存在同步过滤的情况。

　　图六 多实例跨机房迁移架构图

　　具体的做法如下：
　　1.113 针对 7936 实例使用 innobackupex 做数据备份，注意需要指定数据库，并且加上 slave-info 参数；
　　备份完成后，将压缩文件拷贝到 2.117；
　　2.117 创建数据目录以及配置文件涉及的相关目录；
　　2.117 使用 innobackupex 恢复日志；
　　2.117 使用 innobackupex 拷贝数据；
　　2.117 修改配置文件，注意如下参数：replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id；
　　2.117 更改数据目录权限；
　　1.112 授权，使 2.117 有拉取 binlog 的权限（REPLICATION SLAVE， REPLICATION CLIENT）；
　　2.117 CHANGE MASTE TO 1.112，LOG FILE 和 LOG POS 参考 xtrabackup_slave_info；
　　2.117 START SLAVE，查看从库状态；
　　2.117 上建立 7939 的方法类似，不过配置文件需要指定 replicate-wild-do-table；
　　和开发一起进行数据一致性的验证和验证账号权限，以防业务迁走后访问出错；
　　做完上述步骤，可以和研发协调，把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态；
　　如果业务没有问题，证明迁移成功。
　　四、注意事项
　　介绍完不同场景的迁移方案，需要注意如下几点：
　　数据库迁移，如果涉及事件，记住主节点打开 event_scheduler 参数；
　　不管什么场景下的迁移，都要随时关注服务器状态，比如磁盘空间，网络抖动；另外，对业务的持续监控也是必不可少的；
　　CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切记不要找错，如果指定错了，带来的后果是数据不一致或者搭建主从关系失败；
　　执行脚本不要在 $HOME 目录，记住在数据目录；
　　迁移工作可以使用脚本做到自动化，但不要弄巧成拙，任何脚本都要经过测试；
　　每执行一条命令都要三思和后行，每个命令的参数含义都要搞明白；
　　多实例环境下，关闭 MySQL 采用 mysqladmin 的形式，不要把正在使用的实例关闭了；
　　从库记得把 read_only = 1 加上，这会避免很多问题；
　　每台机器的 server_id 必须保证不一致，否则会出现同步异常的情况；
　　正确配置 replicate-ignore-db 和 replicate-wild-do-table；
　　新建的实例记得把 innodb_file_per_table 设置为 1，上述中的部分场景，因为之前的实例此参数为 0，导致 ibdata1 过大，备份和传输都消耗了很多时间；
　　使用 gzip 压缩数据时，注意压缩完成后，gzip 会把源文件删除；
　　所有的操作务必在从节点或者备节点操作，如果在主节点操作，主节点很可能会宕机；
　　xtrabackup 备份不会锁定 InnoDB 表，但会锁定 MyISAM 表。所以，操作之前记得检查下当前数据库的表是否有使用 MyISAM 存储引擎的，如果有，要么单独处理，要么更改表的 Engine。
　　五、 技巧
　　在 MySQL 迁移实战中，有如下技巧可以使用：
　　任何迁移 LOG FILE 以 relay_master_log_file（正在同步 master 上的 binlog 日志名）为准，LOG POS 以 exec_master_log_pos（正在同步当前 binlog 日志的 POS 点）为准；
　　使用 rsync 拷贝数据，可以结合 expect、nohup 使用，是绝妙组合；
　　在使用 innobackupex 备份数据的同时可以使用 gzip 进行压缩；
　　在使用 innobackupex 备份数据，可以加上 –slave-info 参数，方便做从库；
　　在使用 innobackupex 备份数据，可以加上 –throttle 参数，限制 IO，减少对业务的影响。还可以加上 –parallel=n 参数，加快备份，但需要注意的是，使用 tar 流压缩，–parallel 参数无效；
　　做数据的备份与恢复，可以把待办事项列个清单，画个流程，然后把需要执行的命令提前准备好；
　　本地快速拷贝文件夹，有个不错的方法，使用 rsync，加上如下参数：-avhW –no-compress –progress；
　　不同分区之间快速拷贝数据，可以使用 dd。或者用一个更靠谱的方法，备份到硬盘，然后放到服务器上。异地还有更绝的，直接快递硬盘。
　　六 、总结
　　本文从为什么要迁移讲起，接下来讲了迁移方案，然后讲解了不同场景下的迁移实战，后给出了注意事项以及实战技巧。归纳起来，也以下几点：
　　第一，迁移的目的是让业务平稳持续地运行；
　　第二，迁移的核心是怎么延续主从同步，我们需要在不同服务器和不同业务之间找到方案；
　　第三，业务切换需要考虑不同 MySQL 服务器之间的权限问题；需要考虑不同机器读写分离的顺序以及主从关系；需要考虑跨机房调用对业务的影响。
　　读者在实施迁移的过程中，可以参考此文提供的思路。但怎样保证每个操作正确无误地运行，还需要三思而后行。
　　说句题外话，「证明自己有能力重要的一点是让一切都在自己的掌控之中。」