[原]不一样场景下MySQL的迁移方案

一 为何要迁移

 

MySQL 迁移是 DBA 平常维护中的一个工做。迁移，究其本义，无非是把实际存在的物体挪走，保证该物体的完整性以及延续性。就像柔软的沙滩上，两个天真无邪的小孩，把一堆沙子挪向其余地方，铸就心里神往的城堡。

 

生产环境中，有如下状况须要作迁移工做，以下：

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

2.业务出现瓶颈。好比项目中采用单机承担全部的读写业务，业务压力增大，不堪重负。若是 IO 压力在可接受的范围，会采用读写分离方案；

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

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

 

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

二 MySQL 迁移方案概览

 

MySQL 迁移无非是围绕着数据作工做，再继续延伸，无非就是在保证业务平稳持续地运行的前提下作备份恢复。那问题就在怎么快速安全地进行备份恢复。

 

一方面，备份。针对每一个主节点的从节点或者备节点，都有备份。这个备份多是全备，多是增量备份。在线备份的方法，多是使用 mysqldump，多是 xtrabackup，还多是 mydumper。针对小容量（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，架构图如图一。102 从节点的数据容量过大，不能使用 mysqldump 的形式备份。和研发沟通后，造成一致的方案。

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

 

具体作法是这样：

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 充当从节点，架构图如图二。这次迁移只须要迁移指定库，这些库容量不是太大，而且能够保证数据不是实时的。

 

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

 

具体的作法以下：

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

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

三、102 收集指定库须要的帐号以及权限；

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

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

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

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

八、若是业务没有问题，证实迁移成功。

 

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

 

接下来看看一主一从结构双边迁移指定库怎么作。一样是由于业务共用，致使服务器压力大，管理混乱。因而，打算将主节点 101 和从节点 102 同时迁移至新的机器 10三、10四、10五、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 状态；

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

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

1五、若是全部业务没有问题，证实迁移成功。

 

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

 

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

 

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

 

具体的作法是这样：

 

一、研发将 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 的从节点，方法同上；

1三、接下来到了关键的地方了，咱们须要把 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 的从节点了。

1四、业务迁移以前，断掉 103 和 101 的同步关系；

1五、作完上述步骤，能够和研发协调，把 101 的读写业务切回 102，读业务切到 104。须要注意的是，此时 101 和 103 都可以写，须要保证 101 在没有写入的状况下切到 103，可使用 FLUSH TABLES WITH READ LOCK 锁住 101，而后业务切到 103。注意，必定要业务低峰执行，切记；

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

1七、若是业务没有问题，证实迁移成功。

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三、须要注意的是，1.103 的单双号配置须要和 1.101 一致；

1四、作完上述步骤，能够和研发协调，把 1.101 的读写业务切到 1.103，把 1.102 的读业务切到 1.104。观察业务状态；

1五、若是业务没有问题，证实迁移成功。

 

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 = 一、read_only = 一、 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；

十二、和开发一块儿进行数据一致性的验证和验证帐号权限，以防业务迁走后访问出错；

1三、作完上述步骤，能够和研发协调，把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态；

1四、若是业务没有问题，证实迁移成功。

 

四 注意事项

 

介绍完不一样场景的迁移方案，须要注意以下几点：

 

一、数据库迁移，若是涉及事件，记住主节点打开 event_scheduler 参数；

二、无论什么场景下的迁移，都要随时关注服务器状态，好比磁盘空间，网络抖动；另外，对业务的持续监控也是必不可少的；

三、CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切记不要找错，若是指定错了，带来的后果就是数据不一致；

完整内容点此查看