?

下图是 C 项目 MySQL 架构图。

?

?

具体的做法如下：

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

8、105 和 106 新建实例，搭建主从关系，此时的主节点和从节点处于空载；

?

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

?

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

?

11、102 导出 105 需要的指定库数据完毕，使用 rsync 传输到 105，必要时做压缩操作；

?

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

?

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

?

14、上述完成后，和研发协作，将 101 和 102 的业务迁移到 105 和 106，观察业务状态；

?

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

?

3.4，场景四：主一从结构完整迁移主从

接下来看看一主一从结构完整迁移主从怎么做。和场景二类似，不过此处是迁移所有库。因 101 主节点 IO 出现瓶颈，打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104，103 充当主节点，104 充当从节点。迁移完成后，以前的主节点和从节点废弃，架构图如图四。此次迁移是全库迁移，容量大，并且需要保证实时。这次的迁移比较特殊，因为采取的策略是先替换新的从库，再替换新的主库。所以做法稍微复杂些。

?

下面是 D 项目 MySQL 架构图。

?

?

具体的做法是这样：

?

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

?

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

?

3、104 新建 MySQL 实例，建成以后，停止 MySQL 服务，并且将整个数据目录 mv 到其他地方做备份，注意，此处操作的是 104，也就是未来的从库；

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

11、和研发协作，将之前 102 从节点的读业务切到 104；

?

12、利用 102 的数据，将 103 变为 101 的从节点，方法同上；

?

13、接下来到了关键的地方了，我们需要把 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 的从节点了。

?

14、业务迁移之前，断掉 103 和 101 的同步关系；

?

15、做完上述步骤，可以和研发协调，把 101 的读写业务切回 102，读业务切到 104。需要注意的是，此时 101 和 103 均可以写，需要保证 101 在没有写入的情况下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 锁住 101，然后业务切到 103。注意，一定要业务低峰执行，切记；

?

16、切换完成后，观察业务状态；

?

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

?

3.5，场景五：双主结构跨机房迁移

接下来看看双主结构跨机房迁移怎么做。某项目出于容灾考虑，使用了跨机房，采用了双主结构，双边均可以写。因为磁盘空间问题，需要对 A 地的机器进行替换。打算将主节点 1.101 和从节点 1.102 同时迁移至新的机器 1.103 和 1.104，1.103 充当主节点，1.104 充当从节点。B 地的 2.101 和 2.102 保持不变，但迁移完成后，1.103 和 2.101 互为双主。架构图如图五。因为是双主结构，两边同时写，如果要替换主节点，单方必须有节点停止服务。

?

下图是 E 项目 MySQL 迁移架构图。