Mysql必读MySQL多线程复制遇到Error_code: 1872的解决方案

概述介绍《Mysql必读MySQL多线程复制遇到Error_code: 1872的解决方案》开发教程，希望对您有用。

《MysqL必读MysqL多线程复制遇到Error_code: 1872的解决方案》要点：
本文介绍了MysqL必读MysqL多线程复制遇到Error_code: 1872的解决方案，希望对您有用。如果有疑问，可以联系我们。

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

起因 ：由于IDC机房断电(估计又是哪里被挖掘机碰了下吧),导致所有服务器重启,影响到了其中的MysqL数据库.来看下这时数据库遇到的问题：MysqL实例

数据库版本 ：MysqL 5.7.10MysqL实例

问题表现MysqL实例

：从机复制报如下错误：Slave sql for channel ”: Slave Failed to initialize relay log info structure from the repository,Error_code: 1872MysqL实例

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

在MTS场景下,可能会出现以下两个问题：MysqL实例

gap事务：后执行的事务先回放(apply)了
Exec_Master_Log_Pos位置不准确：可能存在已经事务已经提交,但是位置还没更新(单线程复制不存在此问题)
gap事务比较好理解,因为不论是基于database级别的MTS,还是基于logical_clock的MTS,都可能存在下面的这种场景：MysqL实例

MysqL实例

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

另一方面,这时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的更新并不是事务的(这个需要好好体会下).MysqL实例

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

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

START SLAVE UNTIL sql_AFTER_MTS_GAPS;START SLAVE sql_THREAD;

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

不过,当InsIDe升级到MysqL 5.7.15过程时,又遇到了一个不大不小的坑,这个就留着等下回分享吧.MysqL实例

总结

以上是内存溢出为你收集整理的Mysql必读MySQL多线程复制遇到Error_code: 1872的解决方案全部内容，希望文章能够帮你解决Mysql必读MySQL多线程复制遇到Error_code: 1872的解决方案所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。