MySQL 主从relay日志损坏恢复

别怕！MySQL从库接力日志坏了，这下有救了！

听说 MySQL主从同步出了问题，从库报错error 1594， relay日志坏了，是不是愁坏了？别担心，这回有办法了！

之前老办法得重建从库，这要花上老半天时间， especially 当数据量大的时候，那叫一个心塞。但现在有了GTID，这事儿就简单多了！

GTID，全称 Global Transaction Identifier，简单概括就是每个事务都有个独一无二的ID，这样主从之间的日志传输就有了“聪明的导航”。从库只需告诉主库它已经执行过哪些GTID，主库就会自动过滤，只发没执行过的日志过来，这样数据就完美一致了。

那该怎么操作呢？几步走：

1. 先备个份，看看当前同步状态：
show slave statusG

select * from mysql.slave_relay_log_infoG

select * from mysql.slave_master_infoG

2. 关闭复制进程：
stop slave;

3. 重置复制进程，不要用 reset slave all，因为这会把所有配置信息都清空，只用：
reset slave;

4. 最后启动复制进程：
start slave;

这样，从头来过，主从同步就恢复了，再也不用担心relay日志损坏的问题啦！是不是简单又高效？

版本:

        MySQL-5.7.32+GTID

问题:

        MySQL主从同步由于relay日志损坏，导致从库复制报错error: 1594

问题分析:

        在遇到从库relay日志损坏时，重建从库是其中的一个修复办法之一，但该方法的消耗的时间长，效率低，如果遇到数据量大的库，修复时间可能要1个小时以上

        其实，对于从库relay日志损坏，完全可以不用重建从库，在基于GTID的主从同步中，复制进程开启master_auto_position的情况下，从库会将当前已经执行过的gtid集合发送给主库，主库接收到从库发送的gtid集合后，会在现有的binlog里面进行比对，将从库没有执行过的gtid发送给备库,从而保证数据的一致性

        所以，在遇到relay日志损坏，只需要重置复制进程，重新拉取主库的日志就行。

问题解决:

        备份当前从库的同步状态信息       

show slave status\Gselect * from mysql.slave_relay_log_info\Gselect * from mysql. slave_master_info 

        关闭复制进程

stop slave;

         重置复制进程，会清空当前从库全部的relay log，不要使用reset slave all,因为在5.7.24之后，在master_info_repoistory=table的情况下，reset slave会将连接信息保留在内存里面，不需要重新设置change master,而reset slave all会清空全部的relay log以及配置信息

        重置命令

reset slave;

        重新开启复制进程，主从同步恢复 

start slave;