MySQL 主从复制延迟的踩坑

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

情景

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

表的简要设计如下，这里将活动内容字段合并为content展示：

activity_tmp（）
id
status // 审批状态
content //  审批阶段提交的活动内容

activity
id
content // 审批通过后真正展示的活动内容

遇到的问题

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

追查问题回溯

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

当时的问题代码

$intStatus = $arrInput[‘status’];
$this->objActTmp->updateInfoByAId($intActId, $intStatus);
// 更新后，马上查
$arrActContent = $this->objActTmp->getActByStatus($intStatus);

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

解决方案

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

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

对于修改代码逻辑，鄙人有两点见解：

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

总结

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

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