MySQL多线程复制问题处理之Error_code: 1872

上周在生产环境上遇到一个问题,不敢独享,拿出来给小伙伴们做个简单的分享。

起因:由于IDC机房断电(估计又是哪里被挖掘机碰了下吧),导致所有服务器重启,影响到了其中的MySQL数据库。来看下这时数据库遇到的问题:
数据库版本:MySQL 5.7.10
问题表现:从机复制报如下错误:Slave SQL for channel '': Slave failed to initialize relay log info structure from the repository, Error_code: 1872

用了Inside君的MySQL标准配置文件模板,怎么没有实现crash safe呢?其实,这主要是因为多线程复制(MTS)所引起。不知MySQL 5.7,即使MySQL 5.6也同样会遇到问题。

在MTS场景下,可能会出现以下两个问题:

  1. gap事务:后执行的事务先回放(apply)了
  2. Exec_Master_Log_Pos位置不准确:可能存在已经事务已经提交,但是位置还没更新(单线程复制不存在此问题)

gap事务比较好理解,因为不论是基于database级别的MTS,还是基于logical_clock的MTS,都可能存在下面的这种场景:

MySQL多线程复制问题处理之Error_code: 1872-MySQL社区 Inside MySQL Group

由于MTS的原因,后面的事务可能比前面的事务早执行,如上图终可能事务tx2和tx4都已经提交了,但是事务tx1和tx3还未提交。这时就称为存在gap事务。在基于logical_clock的MTS场景下,用户可以通过配置参数slave_preserve_commit_order=1来保证提交的顺序性。

另一方面,这时Exec_Master_Log_Pos也是不准确的,当发生crash时,master info中依然记录的是tx1事务开始执行的位置(见上图右边的部分)。切记,即使将参数slave_preserve_commit_order设置为1,MTS场景下依然不能保证Exec_Master_Log_Pos是准确的,其称之为gap-free low-watermark。因为MTS场景下对于表slave_realy_info_log的更新并不是事务的(这个需要好好体会下)。

然而,MTS场景下引入了新的事务表slave_worker_info,用以表示发生宕机时每个线程更新到的位置,其与Worker线程的回放是事务的。因此,MySQL在恢复的时候可以通过通过Exec_Master_Log_Pos与表slave_worker_info的列Master_log_pos做对比,判断是否需要回放当前事务。

在MySQL 5.7.13版本之前,当发生宕机后需要手动执行如下操作,若直接执行CHANGE MASTER TO操作,则可能会触发上述1872错误:

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
START SLAVE SQL_THREAD;

由于服务器上的MySQL版本为5.7.10,而DBA试图通过命令CHANGE MASTER TO来修复复制问题,因此导致了上述问题。而在MySQL 5.7.13版本后,上述问题将有MySQL自动修复。简单来说,即使发生了宕机,也能准确并自动地恢复复制的运行状态。

不过,当Inside升级到MySQL 5.7.15过程时,又遇到了一个不大不小的坑,这个就留着等下回分享吧。

最后,安利一个活动,IMG社区第二界数据库技术沙龙——上海站将于10月15日举行。本次技术沙龙邀请了来自网易、58同城、车享网、乐岸科技等技术专家前来分享MySQL实战经验。由于,受场地条件约束,仅能邀请30名小伙伴前来参加。感兴趣的小伙伴赶快点击阅读原文进行报名吧,门票免费,先到先得哦~

发表评论

坐等沙发
相关文章
IMG社区MySQL技术沙龙南京站圆满结束
IMG社区MySQL技术沙龙南京站圆满结束
改朝换代:MySQL Group Replication
改朝换代:MySQL Group Replication
数据库行业的朋友圈内幕,不知道就没法混了
数据库行业的朋友圈内幕,不知道就没法…
Inside MySQL Group社区启用新LOGO
Inside MySQL Group社区启用新LOGO
MySQL 5.7 semi-sync 1024 bug 修复
MySQL 5.7 semi-sync 1024 bug 修复
MySQL超越Oracle了?
MySQL超越Oracle了?
Oracle MySQL ACE. Author of Inside MySQL and MySQL Core Series. Great at MySQL performance tuning、troubleshooting、systems availability and scalability、capacity planning, etc.

一触即发,2017年,数据库世界的诸神之战