mysql迁移⽅案_不同场景下MySQL的迁移⽅案
本⽂内容 为什么要迁移
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 主⼀从结构迁移从库架构图
具体做法是这样：
1、研发将 102 的读业务切到主库；
2、确认 102 MySQL 状态(主要看 PROCESS LIST)，观察机器流量，确认⽆误后，停⽌ 102 从节点的服务；
3、103 新建 MySQL 实例，建成以后，停⽌ MySQL 服务，并且将整个数据⽬录 mv 到其他地⽅做备份；
4、将 102 的整个 mysql 数据⽬录使⽤ rsync 拷贝到 103；
之前下过mysql现在重新下载mysql
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 架构图。
图 2 主⼀从结构迁移指定库架构图
具体的做法如下：
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，场景三：主⼀从结构双边迁移指定库
接下来看看⼀主⼀从结构双边迁移指定库怎么做。同样是因为业务共⽤，导致服务器压⼒⼤，管理混乱。于是，打算将主节点 101 和从节点 102 同时迁移⾄新的机器 103、104、105、106，103 充当 104 的主节点，104 充当 103 的从节点，105 充当 106 的主节点，106 充当 105 的从节点，架构图如图三。此次迁移只需要迁移指定库，这些库容量不是太⼤，并且可以保证数据不是实时的。我们可以看到，此次迁移和场景⼆很类似，⽆⾮做了两次迁移。
下图是 C 项⽬ MySQL 架构图。
图 3 主⼀从结构双边迁移指定库架构图
具体的做法如下：
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 架构图。
图 4 主⼀从结构完整迁移主从架构图
具体的做法是这样：
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 互为双主。架构图如图五。因为是双主结构，两边同时写，如果要替换主节点，单⽅必须有节点停⽌服务。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。