mysql replication错误常见处理

大部分的错误，都是日志错误

日志本身的错误

主日志和中继日志都可能出错，可以使用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，其他的就自动恢复

##这里我有点不可思议。。。