大部分的错误，都是日志错误
日志本身的错误
主日志和中继日志都可能出错，可以使用mysqlbinlog来读一下
mysqlbinlog mysql-bin.000007>/dev/null ##只显示错误
mysqlbinlog server3-relay-bin.000004>/dev/null
跳过日志错误
有时候可能是日志的本身没错，但SQL解释出错，比如mysql主从数据的不一致，导致有的M上的操作在slave上执行不下去，从而终止了 replication。此时就可以手动跳过日志，但是有可能出现数据不一致的情况如果主日志出错，可以才slave上执行,如果有多个错误可能要执行多次
传统的复制下，可以执行下面的操作
stop slave；
set global sql_slave_skip_counter = 1; ##最好设定为1，每次只跳过一个错误，这样有利于查看哪里发生了错误，对之后让MS数据一致会有所帮助的
start slave;
但是mysql的GTIDs不支持上面的处理的方法，因为上面的处理是基础
position来进行的
中继日志出错
传统的复制下，可以执行下面的操作
在slave上查看复制的状态，根据日志跳过出错的日志
STOP SLAVE
CHANGE MASTER TO
MASTER＿LOG_FILE＝"replay_master_log_file"
MASTER＿LOG_POS="eexec_master_log_pos"
START SLAVE
同样上面的处理方案只能在传统的复制下使用，但是GTIDs上不能使用
STOP SLAVE
SET GTID＿NEXT＝＂uuid：next_id＂ ##一般next_id当前出错的next_id+1
BEGIN；
COMMIT；
SET GTID＿NEXT＝＂ＡＵＴＯＭＡＴＩＣ＂；
START SLAVE
＊只需要修改其中的一台的slave，其他的就自动恢复
##这里我有点不可思议。。。