mysql主从复制跳过复制错误

52037317

　　跳过复制错误
　　mysql因为binlog机制问题，有些时候会出现从库重放sql执行失败的情况，特别是旧的STATEMENT模式最容易出现这种情况（因为函数和存储过程等原因），这也是为什么强调使用mixed和row模式的原因。另外就是一些外部XA事务，因为XA事务日志不在mysql中，有时候会出现回滚失败的情况，导致主从报错。
　　出现这些状况那该怎么办好呢？如果是重做，虽然是可以，但是如果库非常大，那耗时就不是一两小时那么容易，如果是做了生产读写分离的，就不好交代了。这个时候我们可以选择手动修改数据，然后跳过这个复制错误，然后这个主从复制就会重新运行了。
　　继续讲述两种模式，先说的是GTID模式，他可以有两种方式跳过。第一种是用得比较多的，注入空事务跳过：
#找到冲突的GTID号.　　
mysql>show slave status\G
　　
    。
　　
    。
　　
    。
　　
Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451
　　
    。
　　
    。
　　
    。
　　
#停止复制
　　
mysql>stop slave;
　　
#然后执行设置一个事务GTID来跳过，就是要跳过这个事务的意思
　　
mysql>SET gtid_next = '09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451';
　　
#注入空事务
　　
mysql>BEGIN;COMMIT;
　　
#把GTID设置回自动模式
　　
mysql>SET gtid_next = 'AUTOMATIC';
　　
#重新开启复制
　　
mysql>START SLAVE;
　　
#这就可以跳过一个事务了,原理在于通过执行一个空事务代替master传递过来的冲突事务.
　　
#当然跳过了，并不代表这个数据就不修改了，还是要你手动去修改一下，这样就一切回归正常了
　　
mysql>update tables set 。。。。。。。
　　第二种，直接跳过这个GTID，改做后面的
#找到冲突的GTID号.　　
mysql>show slave status\G
　　
    。
　　
    。
　　
    。
　　
Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451
　　
    。
　　
    。
　　
    。
　　
#停止复制
　　
mysql>stop slave;
　　
#直接设置上面的GTID值+1
　　
mysql>SET @@GLOBAL.GTID_PURGED='09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648452';
　　
#重新开启复制
　　
mysql>START SLAVE;
　　
#当然跳过了，并不代表这个数据就不修改了，还是要你手动去修改一下，这样就一切回归正常了
　　
mysql>update tables set 。。。。。。。
　　然后就说传统模式了，相对来说，更简单一些
#停止复制　　
mysql>slave stop;
　　
#设定跳过一个事务
　　
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1
　　
#重新开启复制
　　
mysql>slave start
　　
#这样就正常了，但是，当然还是要把数据修改上去
　　
mysql>update tables set 。。。。。。。
　　其实还有一个禁忌设定方式，可以跳过一些复制报错，因为不建议，只是拿出来说说可以这么干
#修改配置文件　　
vim /etc/my.cnf
　　
[mysqld]
　　
#跳过指定error no类型的错误
　　
#slave-skip-errors=1062,1053,1146
　　
#跳过所有错误
　　
#slave-skip-errors=all