记一次 MySQL 主从复制延迟的踩坑

最近开发中遇到的一个 MySQL 主从延迟的坑,记录并总结,避免再次犯同样的错误。

情景

一个活动信息需要审批,审批之后才能生效。因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity)。表的简要设计如下,这里将活动内容字段合并为content展示:

遇到的问题

当时是有编辑触发审批的情况,发现审批通过之后活动内容是空的,于是开始追查问题的原因。这里说一句,当程序出问题的时候,95%都是代码的问题,先不要去怀疑环境出问题。好好的查日志,然后看看你的代码吧。

追查问题回溯

1、查activity_tmp表,发现当时提交审批的活动内容是正常的,而且状态也更新为审批通过了,怀疑是写入activity表失败 2、查activity表,发现审批后的内容确实没有写入,怀疑是代码问题 3、查看代码,代码逻辑没看出问题,怀疑数据库操作失败,查看日志 4、日志显示,有一句insert语句的活动内容为空,活动内容来自上一个mysql执行的是select语句,把该select语句拿出来放到线上的备库查询,发现活动内容是存在的。运行时查询为空,执行完毕后查询时内容存在,初步怀疑是主从延迟问题。 5、报错只是部分失败,确定是主从延迟的问题。

当时的问题代码

这就是主从延迟出现的地方,update后,马上get,这是主从复制架构上开发的一个大忌。

解决方案

这类问题的解决方案有两种:

  • 修改代码逻辑
  • 修改系统架构

对于修改代码逻辑,鄙人有两点见解:

  • 如果第二步获取的数据不需要第一步更新的status字段,那就先读,然后再更新
  • 如果第二步获取的数据需要依赖第一步的status字段,那就在读出来的时候先判断是否为空,如果是空的,报错,下一次重试。

总结

其实之前也听到过这样的例子,但是由于没有亲身经历,所以只保留了一种理论上的记忆,实际上印象不深,经历了这么一次踩坑后,印象特别深刻,现在看到别人写这样的代码也能马上发现并指出。还是自己亲身去踩坑印象最深。

日志很重要,详细的日志更重要。日志要记录有用的信息,方便追查问题的时候去追溯问题的本质原因。我觉得日志就应该尽量做成飞机中的黑匣子,帮助我们保存“事故“发生时的所有相关信息。

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

1 1 收藏 评论

关于作者:hoohack

一个正在努力的菜鸟 个人主页 · 我的文章 · 27 ·      

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部