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

标签: IT技术 MySQL 数据库 | 发表时间:2017-07-16 08:32 | 作者:hoohack
出处:http://blog.jobbole.com

最近开发中遇到的一个 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字段,那就在读出来的时候先判断是否为空,如果是空的,报错,下一次重试。

总结

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

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

记一次 MySQL 主从复制延迟的踩坑,首发于 文章 - 伯乐在线

相关 [mysql 复制] 推荐:

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

MySQL主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.

MySQL半同步复制(Semisynchronous Replication)

- - IT技术博客大学习
MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成.

MySQL 5.6 测试之 Replication(主从复制)

- - MySQL 中文网 -
MySQL 5.6测试之Replication. MySQL 5.6版本相比以前新增了很多令人激动的特性,简要介绍见: 转:MySQL 5.6新特性. 性能方面已经做过测试了,详细请见: MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试.

[玩转MySQL Replication] 复制拓扑

- - CSDN博客数据库推荐文章
     朴实简单的才是真、那些高端洋气的复制拓扑纯属自虐.      实施复制大概会有 4 个原则:.      ① 一个主库可以有多个备库.      ② 一个备库只能有一个主库.      ③ 每个备库 Server ID全局唯一.      ④ log_slave_updates 有薪火相传之效用.

MySQL主从复制与读写分离

- - 数据库 - ITeye博客
MySQL主从复制与读写分离. MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践. Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过. 但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面.

MySQL主从复制讨论纪要

- - ITeye博客
读了一篇技术文章,和架构部的全体兄弟们进行了讨论. 《mysql主从复制的优缺点》. 1.区分主从进行理解:从库关心顺序、不关心执行时长;. 2.时间 ==> 序号:根据主库的执行情况生成的序号,从库只能根据序号保证先后顺序. 4.从库不能保证强一致性(select),只能保证最终一致性. 应用场景:对于多表更新的场景效果特别好.

MySQL Gtid复制方案学习

- - 小火箭
MySQL从5.6开始出了新的主从复制解决方案: Replication with Global Transaction Identifiers. 在整个复制集群中能够唯一的标识一个事务. 确保同一个事务只会被执行一次. 无法使用 CREATE TABLE. SELECT statements语句.

MySQL 主从复制添加slave

- - 小火箭
在已有的MySQL主从复制下添加slave的方法:. 1、在已有的slave上,执行 stop slave io_thread;,等待Slave_open_temp_tables为0时,执行 stop slave sql_thread;. 2、然后执行 flush tables with read lock;和 flush logs;.