产业气象站|MySQL集群数据问题修复小记
9
分钟
速读仅需7分钟
最近有一套集群有数据不一致的报警 ， 最开始没有引起注意 ， 整体的拓扑结构如下 ， 这是一个偏日志型写入业务 ， 上层是使用中间件来做分库分表 ， 数据分片层做了跨机房容灾 ， 一主两从 ， 而且基于Consul域名管理 ， 也算是跨机房高可用 。
文章图片
因为近期需要把这一套集群跨机房迁移到新机房 ， 整体的方案和设计都算是高大上的 ， 根据之前的切换都是秒级（2-3秒左右）闪断完成 ， 业务初期是不需要做任何调整的 ， 整体来说对业务是平滑无感知的 。
在迁移前在处理主从数据不一致的情况时 ， 发现问题有些蹊跷 ， 总是有个别的数据在从库会出现自增列冲突的情况 ， 设置了从库slave_exec_mode为idempotent幂等后 ， 能够临时解决问题 ， 但是总归是不严谨的 ， 所以和团队讨论了一番 ， 决定重构从库 。
我们认为当前的拓扑架构是这样的 ， 打算是基于物理备份的模式来做 。
文章图片
没想到这个过程中因为数据量较大 ， 备份中基于虚拟环境 ， IO负载很高 ， 导致MHA的pinginsert检查超时失败 ， 所以我们看到的一个数据分片的拓扑结构是这样的 。 （MHA目前不允许跨机房自动切换） 。
文章图片
碰到这个问题 ， 着实让我有些抓狂 ， 而因为Consul健康检查不严谨的原因 ， 有一部分的数据其实是写入到原来的两个Master上面了 。 这种混写持续了一段时间 ， 而雪上加霜的时 ， 这个过程的报警有不好使了 ， 确实比较尴尬 ， 所以我们需要立刻采取有效措施来修复数据 。
分析了整体的数据情况 ， 如果保留已有的拓扑结构 ， 建立反向复制关系 ， 应该是比较合理的 ， 但是NewMaster到OldMaster的反向复制关系建立失败（因为binlog保留时间短 ， 有缺失 ， 雪上加霜2.0） ， 我们决定先把数据源切换到原主库OldMaster ， 这个时候新主库上面的数据势必会比主库上要多,但是我们在这个时候还有一些缓和的余地 。
文章图片
这个时候搭建从库的过程是很关键的 ， 因为整个环境没有一个基准了 ， 需要快速修复 ， 我们开始基于时间范围做两端数据的比对工作 ， 整个工作比想象的扼要快一些 。
文章图片
大体的思路就是在新机房搭建一个新的中间件 ， 配置两套schema环境 ， 这样就可以比对两个数据库中的数据情况了 ， 我从数据量小的一些表开始逐步排查 ， 经过一些比对 ， 排除了这个过程中数据混写的状态 。
数据状态整体是这样的：
oldmasternewmaster556691011151516161717
所以在确认之后 ， 我们开始快速搭建从库 ， 停止了MHA之后 ， 我们直接停止了NewMaster实例, ， 然后直接拷贝整个数据目录到跨机房的环境中 ， 这种方式简单粗暴 ， 但是确实有效 。 有的朋友肯定会说这个过程不严谨 ， 一定会丢数据 ， 确实是 ， 但是我们打算很快把数据源切回来 。
文章图片
因为数据比对的过程是比较敏感的 ， 基本都是全表扫描 ， 而且在当时的情况下 ， 能够完成数据比对我们才能够真正放心数据不是我们理解中的“随机写” ， 所以这个过程是确保要做验证的 ， 验证完后有细微的数据修复 ， 可以直接修复 ， 整体还是可控的 。 所以在完成从库之后 ， 我们把数据源切回了NewMaster,毕竟这是经过稽核确认的一个准确的数据源 。
推荐阅读
- 产业气象站|5G基站太耗电！三大运营商正式官宣：将智能化关闭5G基站节约电费
- 产业气象站|他从不打无准备之仗，华为联手哈工大究竟想干啥？依任总性格
- 产业气象站|G是否影响健康？，张朝阳用手机保持30厘米
- 爱集微APP|“芯”势力助推游戏产业发展，芯片成为ChinaJoy的关键词之一
- 产业气象站|电力机器人“小白”上岗巡检
- 产业气象站|苏宁智能宣布五项Biu+共享政策，从生态赋能到生态共享
- 产业气象站|点赞“中国芯里的南大智慧”！华为公司CEO任正非一行访问南京大学
- 产业气象站|花多少钱收购，微软正在谈判收购TikTok美国业务
- 产业气象站|包括王兴，马云创办支付宝的本质不是为了支付，很多人没理解
- 上观新闻|半导体产业如何发展？嘉定举办的这个论坛指明了方向