不同场景下 MySQL 的迁移方案
一、为什么要迁移
MySQL 迁移是 DBA 日常维护中的一个工作。迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性。就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡。
生产环境中,有以下情况需要做迁移工作,如下:
- []磁盘空间不够。比如一些老项目,选用的机型并不一定适用于数据库。随着时间的推移,硬盘很有可能出现短缺;[/][]业务出现瓶颈。比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负。如果 IO 压力在可接受的范围,会采用读写分离方案;[/][]机器出现瓶颈。机器出现瓶颈主要在磁盘 IO 能力、内存、CPU,此时除了针对瓶颈做一些优化以外,选择迁移是不错的方案;[/][]项目改造。某些项目的数据库存在跨机房的情况,可能会在不同机房中增加节点,或者把机器从一个机房迁移到另一个机房。再比如,不同业务共用同一台服务器,为了缓解服务器压力以及方便维护,也会做迁移。[/]
- []研发将 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 的从节点,方法同上;[/][]接下来到了关键的地方了,我们需要把 104 变成 103 的从库;[/][]104 STOP SLAVE;[/]
- []业务迁移之前,断掉 103 和 101 的同步关系;[/][]做完上述步骤,可以和研发协调,把 101 的读写业务切回 102,读业务切到 104。需要注意的是,此时 101 和 103 均可以写,需要保证 101 在没有写入的情况下切到 103,可以使用 FLUSH TABLES WITH READ LOCK 锁住 101,然后业务切到 103。注意,一定要业务低峰执行,切记;[/][]切换完成后,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
- []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 = 1、read_only = 1、 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;[/][]和开发一起进行数据一致性的验证和验证账号权限,以防业务迁走后访问出错;[/][]做完上述步骤,可以和研发协调,把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
- []数据库迁移,如果涉及事件,记住主节点打开 event_scheduler 参数;[/][]不管什么场景下的迁移,都要随时关注服务器状态,比如磁盘空间,网络抖动;另外,对业务的持续监控也是必不可少的;[/][]CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切记不要找错,如果指定错了,带来的后果就是数据不一致或者搭建主从关系失败;[/][]执行脚本不要在 $HOME 目录,记住在数据目录;[/][]迁移工作可以使用脚本做到自动化,但不要弄巧成拙,任何脚本都要经过测试;[/][]每执行一条命令都要三思和后行,每个命令的参数含义都要搞明白;[/][]多实例环境下,关闭 MySQL 采用 mysqladmin 的形式,不要把正在使用的实例关闭了;[/][]从库记得把 read_only = 1 加上,这会避免很多问题;[/][]每台机器的 server_id 必须保证不一致,否则会出现同步异常的情况;[/][]正确配置 replicate-ignore-db 和 replicate-wild-do-table;[/][]新建的实例记得把 innodb_file_per_table 设置为 1,上述中的部分场景,因为之前的实例此参数为 0,导致 ibdata1 过大,备份和传输都消耗了很多时间;[/][]使用 gzip 压缩数据时,注意压缩完成后,gzip 会把源文件删除;[/][]所有的操作务必在从节点或者备节点操作,如果在主节点操作,主节点很可能会宕机;[/][]xtrabackup 备份不会锁定 InnoDB 表,但会锁定 MyISAM 表。所以,操作之前记得检查下当前数据库的表是否有使用 MyISAM 存储引擎的,如果有,要么单独处理,要么更改表的 Engine。[/]
- []任何迁移 LOG FILE 以 relay_master_log_file(正在同步 master 上的 binlog 日志名)为准,LOG POS 以 exec_master_log_pos(正在同步当前 binlog 日志的 POS 点)为准;[/][]使用 rsync 拷贝数据,可以结合 expect、nohup 使用,绝对是绝妙组合;[/][]在使用 innobackupex 备份数据的同时可以使用 gzip 进行压缩;[/][]在使用 innobackupex 备份数据,可以加上 --slave-info 参数,方便做从库;[/][]在使用 innobackupex 备份数据,可以加上 --throttle 参数,限制 IO,减少对业务的影响。还可以加上 --parallel=n 参数,加快备份,但需要注意的是,使用 tar 流压缩,--parallel 参数无效;[/][]做数据的备份与恢复,可以把待办事项列个清单,画个流程,然后把需要执行的命令提前准备好;[/][]本地快速拷贝文件夹,有个不错的方法,使用 rsync,加上如下参数:-avhW --no-compress --progress;[/][]不同分区之间快速拷贝数据,可以使用 dd。或者用一个更靠谱的方法,备份到硬盘,然后放到服务器上。异地还有更绝的,直接快递硬盘。[/]
- []第一,迁移的目的是让业务平稳持续地运行;[/][]第二,迁移的核心是怎么延续主从同步,我们需要在不同服务器和不同业务之间找到方案;[/][]第三,业务切换需要考虑不同 MySQL 服务器之间的权限问题;需要考虑不同机器读写分离的顺序以及主从关系;需要考虑跨机房调用对业务的影响。[/]