01 问题描述
在生产环境中，我们经常会遇见MySQL主从复制断开的情况，在遇到主从复制断开是，通常情况，解决问题的步骤如下：
1、从库上show slave status查看复制断开的直观原因，并记录当前的复制位点
2、查看error log，分析更详细的复制断开原因
3、修复主从复制关系
4、如果复制关系无法修复，则需要重新搭建从库
02 解决问题的方法
主从复制关系断裂，有各种各样的原因。有些时候，我们没有时间去客观分析原因，因为应用程序处于无法使用状态，需要立即恢复，这种情况下，我们对复制断裂问题和服务可用性之间必须做一个权衡，然后再进行相应的处理。
常见的解决主从复制断裂的方法有以下几种：
1、找到其他从库，快速替换
这种方法，需要你的应用具有至少一主两从的架构，其中一个从库发生问题，可以将另外一个从库快速上线，从而恢复应用访问，后续再来排查出现故障的从库的具体问题原因。
2、跳过复制失败的错误
有些情况下，我们可以判断主从复制断裂的原因，例如主库上比从库上多一个数据库db_1,那么当我们在主库上执行drop database db_1的时候，从库的复制一定会断开。这种情况下，我们可以通过跳过一个事务来解决。
方法一：(直接跳过当前事务)
在GTID模式下，可以通过下面的命令来解决：
mysql> STOP SLAVE;
mysql> SET GTID_NEXT='xxxxxx:yyy'; ----- 设置需要跳过的gtid event
mysql> BEGIN;COMMIT;
mysql> SET GTID_NEXT='AUTOMATIC';
mysql> START SLAVE;
在非GTID模式下，可以通过下面的命令来解决：
stop slave;
set sql_slave_skip_counter=1;
start slave;
方法二：(指定新位置)
如果我们通过binlog分析，知道了下一个事务的具体点位，也可以指定下一个事务具体位置的方法来解决：
GTID模式下：
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> SET @@GLOBAL.GTID_PURGED ='xxxxxxx：yyyyyy' ----- 表示这些gtid event已经执行过了
mysql> START SLAVE;
注意，GTID_PURGED 必须是 GLOBAL，上面的命令也可以写成set global gtid_purged='xxx:yyy'
非GTID模式下：
stop slave;
change master to master_log_file='mysql-bin.001360',master_log_pos=676383371;
start slave;
方法三：pt-slave-restart工具
如果我们跳过一个事务之后，还出现断开的场景(例如我们在从库上删除了100条数据，但是主库要更新这100条数据)，可以使用pt-slave-restart这个工具，它可以连续跳过断开的位置。
它的使用方法如下：
pt-slave-restart -h 10.xxx.xxx.xxx -P port -u user -p password
当我们使用并行复制的时候，pt-slave-restart可能会出现报错，这个时候我们可以通过将并行复制修改为单线程复制，然后再使用pt-slave-restart工具，可以参考这篇文章：
方法四：设置参数slave_exec_mode
这个参数可以修改主从复制过程中的从库执行模式，如果是strict严格模式，则所有的复制一旦报错就会停止，如果设置成idempotent幂等模式，则特定错误号的错误将会被跳过。命令如下：
set global slave_exec_mode = idempotent
具体可以参考之前的文章：
这篇文章中还有其他两种跳过复制错误的参数，分别是slave_skip_errors、sql_slave_skip_counter
3、利用备份重建从库
这种方法的使用场景不多，通常情况下，只有从库已经不可用或者无法从主库同步的时候，才会考虑这种方法，例如主库上执行了reset master操作，导致所有的binlog被清理了，这样从库就无法获取读取正确的binlog，复制就会断开，这种情况下，重建从库可能是唯一的办法了。
以上就是MySQL主从复制断开的常用修复方法的详细内容，更多关于MySQL主从复制断开修复的资料请关注三水点靠木其它相关文章！
MySQL主从复制断开的常用修复方法
- Author -
DBA随笔声明：登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。
Reply on: @reply_date@
@reply_contents@