-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
线上业务，最后一次内测阶段；
背景：MySQL-5.7.12
问题发生的现象：
收到报警信息，业务主库A的心跳检测失败，将备库B升级为业务主库；
问题发生的原因：
业务主库A的数据文件目录的磁盘空间剩余量为0%；
问题解决的过程：
磁盘空间写满以后，DML语句无法将数据变更落盘，因此导致业务主库不可用；
所以处理方式也很简单，清理一部分空间以后，purge掉了一些已经备份过的binlog；
不过在处理中发现一个问题，replication slave在报错；
查看mysql的error-log，可以看到如下信息：
与此同时，不管是start slave还是change master都无法完成，会在error-log中不断的刷新类似的错误信息；
由于业务主库A降级是在磁盘空间写满以后，所以可以确认备库B上的业务操作不可能会在A上面执行，两个库之间不会有一致性的问题；
于是选择了reset slave all+change master的方式，重新恢复了同步；
故障报告写完以后，再详细研究一下这种现象的原因：
找到一个bug记录：发生于MySQL-5.6
http://bugs.mysql.com/bug.php?id=77496
并且在5.7.12中也发现过：
https://bugs.mysql.com/bug.php?id=80102
在comment中，提到了relay_log_recovery=ON和 slave-parallel-type=LOGICAL_CLOCK时会出现这个问题；
恰好正在出问题的库也是这种设置；
发生错误的原因：
基于在5.6的Group Commit特性，5.7中实现了Mutil-Thread-Slave的特性，多个线程会同时复现relay-log中， 同一组的事务；
因此 multi-threaded replication slave在运行过程中，如果意外的停止了，由于无法确认事务的一致性，在开启了relay_log_recovery的情况下，会出现如截图中的信息；
官方推荐的恢复步骤：
1.设置 relay_log_recovery=0；
2.启动slave的时候，带上特殊命令： START SLAVE UNTIL SQL_AFTER_MTS_GAPS ；
3.设置relay_log_recovery=1；
非常重要的一点：relay_log_recovery不是一个动态的参数，需要重启数据库实例；
这个问题在5.7.13得到了修复，整个操作步骤会在重启的时候自动进行；重启的时候...重启的...重启...
虽然和bug文档以及官方描述的场景不同，不过上文中出现的情况应该是同一个原因造成的；
好在能够确认A库上的multi-threaded replication slave不可能出现事务不一致的情况，所以就简单粗暴的清除了slave的信息，然后重新进行了同步；
PS：GTID大法好~
