赞助商

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

lytword2015-09-15楼主
一 为什么要迁移

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 的形式备份。和研发沟通后,形成一致的方案。

[img=MySQL,迁移,方案]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150914/2083154086.jpg[/img]
图一 一主一从结构迁移从库架构图

具体做法是这样:

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 充当从节点,架构图如图二。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。

[img=MySQL,迁移,方案]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150914/-190587642.jpg[/img]
图二 一主一从结构迁移指定库架构图

具体的做法如下:

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 的从节点,架构图如图三。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。我们可以看到,此次迁移和场景二很类似,无非做了两次迁移。

[img=MySQL,迁移,方案]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150914/-2078244902.jpg[/img]
图三 一主一从结构双边迁移指定库架构图

具体的做法如下:

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 充当从节点。迁移完成后,以前的主节点和从节点废弃,架构图如图四。此次迁移是全库迁移,容量大,并且需要保证实时。这次的迁移比较特殊,因为采取的策略是先替换新的从库,再替换新的主库。所以做法稍微复杂些。
完整内容点此查看
回复
高级模式
解放号
解放号

加入小组

一个平台,一种生活,解放号 启航