[MYSQL案例][016] 切换 旧环境MySQL 到 新环境MySQL

环境

从一套旧的 主从mysql 切换到新的主从mysql

旧环境配置差一点(新环境的1/4的内存和CPU), 还是机械盘, 故想迁移到新环境

本次使用 A主,A备 表示旧环境的主库和备库, B主和B备表示新环境的主备

实际切换过程和相关问题处理

切换前, 搭建新环境的主从, 并从旧环境同步数据过来, 差不多就是下图这样

但要保障切换后应用验证失败还能回退, 所以还得搭建一个反向的主从(A主同步B主的数据)

切换过程

0. 检测 B主 延迟, 如果太大, 就不适合做切换, 有时间的还可以做下数据一致性校验

1. 停掉应用, 并设置 A主 只读(还有连接,就kill掉)

2. 等待B主复制完成后, B主 开启读写(并停掉复制进程,再reset slave).

3. 4个实例均开启GTID(之前未使用GTID,本次切换过程顺便就开启GTID)

4. 使用GTID搭建主从关系, 并配置反向同步(A主同步B主的数据)

5. 检测主从状态, 并让业务开始测试

第5步的时候 发现A备没收到新的数据, 但A主 有, 也就是A主 未开启log_slave_updates参数.

故修改配置文件该参数后重启 A主. 然后查看A备主从正常.

目前看起来还是很顺利的, 于是又去检测了下主从状态.

B备 正常, 但A主报错, 主键冲突

在 A主上 查询该数据确实存在, 查看binlog发现确实是A主写的, 使用show processlist查看有应用连接到A主写数据......

原理之前修改参数重启A主后, 未设置A主只读, 而应用又恰好还有部分未修改IP信息就启动了, 于是就又连接到A主写数据了.

这部分数据是非事务数据, 偏向于每天要定期修改的那种, 比如修改URL,或者每天需要跑的JOB之类的.

处理方法: 赶紧设置 A主 只读, 然后跳过那部分主键冲突的数据

总结

1. 在未使用gtid的环境, 建议启用gtid, 可以在线开启GTID,只需要重新change master即可.

2. 如果有级联, 或者这种反向切换的要求时, 注意log_slave_updates参数, 该参数决定是否将relay log写入binlog

3. 建议使用域名或者VIP, 不然业务还得修改IP信息, 而又有可能未修改完...

运行一段时间没问题后, 就可以先关闭 旧环境 服务器了,

再过一段时间也没问题后, 就可以回收旧环境资源了.