mysql数据库迁移方案_不同场景下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，注意不要和 1