如何恢复MySQL主从数据一致性

最近被告知，MySQL主从数据库的数据不一致，猜测备库在同步过程中出现了问题，于是，登上备库，使用 mysql> show slave status/G查看，果然，备库在insert语句中因违反主键约束，导致备库停止了同步。现在的问题很明确，就是如何恢复主从库数据的一致性。

可选方案如下：

一、查看Master最新的Position，将其作为Slave复制的起点。

这种思路体现的是过去的不一致既往不咎，现在保持同步即可。看起来，这个思路和恢复主从库数据的一致性的初衷有所违背，但这种方法，简单，高效，在测试环境，对历史数据要求不高的场景中可使用。

二、必须严格的恢复主从库数据的一致性。

在这里，也有两种思路：

1. 备份主库数据，并在从库上恢复，在历史数据一致性的基础上开启同步，但这种方法比较麻烦，必须在主库上执行锁表操作，阻止客户端对于表数据的更新操作，而且在数据量大的情况下，备份也是个耗时的工程。其实，这种方法在实际生产环境中也很少用。

2. Skip掉相关错误

其实，这个说活不是很严谨，准备的说，是跳过相关的事务。在我今天这种情况下，就是skip掉因违反主键约束而失败的insert语句。

如何跳过相关事务

一、停止slave服务

二、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

三、开启slave服务。

这里跳过的是一个事务。当然，也可以跳过多个事务，但要谨慎，毕竟，你并不知道跳过的是什么事务。

建议：可反复执行上述步骤，仔细查看导致从库不能同步的语句。有的时候，阻止从库的事务太多，这种方法就显得略为低效。

可分析主库日志的事务，来确定SQL_SLAVE_SKIP_COUNTER的合适值。具体步骤如下：

1、在备库中执行show slave status/G，确认以下两个参数

根据上述两个参数的值，在主库中查看当前阻碍从库复制的事务以及之后的事务。

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776;

这个是查看日志文件mysql-bin.000217中事务ID为673146776后的所有事务。

当然，SHOW BINLOG EVENTS的用法还是相当灵活的，下述方式均可。

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776/G

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776 limit 10;

也可在主机环境下通过mysqlbinlog命令查看

如何查询语句的执行情况

在从库跳过相关事务，重新启动Slave后，Slave_IO_Running，Slave_SQL_Running两项均显示“YES”，但Seconds_Behind_Master并没有马上下降，反而缓慢上升。