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场景下，可能会出现以下两个问题：

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

由于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过程时，又遇到了一个不大不小的坑，这个就留着等下回分享吧。