您当前的位置:首页 > 计算机 > 软件应用 > 数据库 > MySQL

stop slave卡住--事务的事件没有复制完整

时间:09-30来源:作者:点击数:

在文章stop slave卡住,初步介绍了stop slave的问题现象以及一些原因。

以及文章stop slave 卡住模拟–大事务场景中,介绍了大事务场景中,stop slave的模拟。

本文介绍另外一种情况:一个事务的事件没有完整复制到从库。

主从架构中,在主库上更新数据后,会写入binlog,并复制到从库。

在事务型存储引擎中,如innoDB,数据更新以事务为单位。

一个事务通常有很多event组成,例如begin, commit,query, write_rows等等。

在主库上提交一个事务,事件写入binlog,再复制到从库,从库接着开始回放binlog。从库回放binlog,并不是一个事务的所有event都复制过来以后,才开始回放的,而是一边I/O线程接收binlog日志,一边SQL 线程应用binlog日志。

这样,就可能存在一个问题,如果一个事务的event比较多,只将一部分event复制到从库,此时主库故障 或 网络断开,从库上一直无法接收剩余的event,导致SQL线程一直在等待剩余event。

在这个时候,在从库上执行stop slave,SQL 线程会等待,直到超过等待时间(默认60s),然后回滚事务。

基本的排查思路:

  1. 查看大事务正在执行的event(预先有大事务监控,可以采集正在执行的event)。
  2. 查看从库的错误日志,确定当时从库正在复制的主库的日志位点。使用这个日志位点,在老主库的binlog中查找对应的事件。
  3. 分析原因:
    • 如果正在执行的是begin事件,且从库复制位点对应的事件不是commit,则可以得出,导致stop slave 超时的原因是事务的事件没有接收完整。
    • 正在执行的SQL是 正常更新SQL,则导致stop slave超时原因可能是事务比较大,实际执行很耗时,也可能是事件没有接收完整(因为无法确定正在执行的事务与正在复制的事务是否同一个)。
方便获取更多学习、工作、生活信息请关注本站微信公众号城东书院 微信服务号城东书院 微信订阅号
推荐内容
相关内容
栏目更新
栏目热门
本栏推荐