原因：由于IDC机房的电源故障（估计它会受到挖掘机的攻击），所有服务器都重新启动并影响MySQL数据库：
MySQL数据库版本：5.7.10
问题的表现
从机器复制以下错误：通道的从SQL：从初始化中继日志信息结构失败
用内部的MySQL标准配置文件模板，怎样才能不崩溃安全地实现呢事实上，这主要是由于多线程复制（MTS）造成的，我不知道MySQL 5.7，甚至MySQL 5.6也会有问题。
在MTS场景中，可能存在两个问题：
间隙事务：事务执行第一次播放（应用）
exec_master_log_pos定位不准确：有可能已经交易已经提交，但位置尚未更新（单线程复制不存在）
缺口交易更好的理解，因为无论是MTS基于数据库级或MTS基于logical_clock，可能有以下情况：
由于MTS的原因，后一个事务可能比前面的事务提前执行。例如，交易TX2和TX4可在图年底交房，但交易TX1和TX3尚未提交。这就是所谓的差距，交易的存在。在基于logical_clock MTS的情况，用户可以确保通过配置参数slave_preserve_commit_order = 1提交订单。
另一方面，exec_master_log_pos也不准确，此时。当发生崩溃时，掌握信息仍然记录TX1交易执行的位置（见右上图的一部分）。记住，即使slave_preserve_commit_order参数设置为1，该方案仍不能保证exec_master_log_pos是准确的，这是所谓的无缝隙low-watermark.because的表在MTS的场景slave_realy_info_log更新是不是一个交易（需要很好的理解）。
然而，该方案引入了一个新的事务表slave_worker_info，每个线程更新工人下位置说，和线程重播事务。因此，当MySQL恢复，它可以通过exec_master_log_pos和表slave_worker_info柱slave_worker_info决定是否重播当前交易比较。
在MySQL 5.7.13版本，当停机时需要手动执行以下操作后，如果更改主的直接实施，可能会引发1872错误：
直到sql_after_mts_gaps开始奴隶；
开始从sql_thread；
因为服务器上的MySQL版本5.7.10，和DBA通过命令更改主修复复制问题，造成的问题是，MySQL 5.7.13版本后，上述问题将MySQL的自动修复。简单来说，即使宕机的发生，可以准确、自动恢复运行状态复制。
然而，当在升级到MySQL 5.7.15过程中，遇到了一个小坑，这将等到下一次分享。
