最近被告知，mysql主从数据库的数据不一致，猜测备库在同步过程中出现了问题，于是，登上备库，使用 mysql> show slave status\g查看，果然，备库在insert语句中因违反主键约束，导致备库停止了同步。现在的问题很明确，就是如何恢复主从库数据的一致性。
可选方案如下：
代码如下:
# mysqlbinlog mysql-bin.000217 --start-position=673146776
如何查询语句的执行情况
在从库跳过相关事务，重新启动slave后，slave_io_running，slave_sql_running两项均显示“yes”，但seconds_behind_master并没有马上下降，反而缓慢上升。
这时候，通过show processlist语句查看线程的执行情况，发现第一条语句执行时间太长，“state”列显示“sending data”。关于“sending data”的含义，官方说明如下：
可见，该语句涉及了大量的磁盘读。
为了进一步分析该语句的耗时分布，可设置profiling变量。步骤如下：
一、在查询开始之前，设置set profiling=on;
二、在语句执行完毕后，通过show profiles查看语句的query_id。
三、通过show profile for queryquery_id 查看语句的具体执行情况。
最后也发现，该语句在sending data阶段耗时过久。
总结：
1. 在执行stop slave的时候，stop slave命令被hang住了，在网上查询了相关资料，可能与slave中有长sql或locked的sql执行有关，在这里，除show processlist外，最好不要执行show slave status以及slave stop等slave相关命令。那么如何解决该问题呢？等待锁定slavesql的线程结束，或者重启数据库。我选择了后者。
2. 在重启备库的过程中，还有段小插曲，在执行start slave命令的时候，报如下错误：error 1872 (hy000): slave failed to initialize relay log info structure from the repository。网上很多资料都是推荐重新配置主从集群，这样又回到了开头的方案选择部分了。奇怪的时，我关闭了从库，重新启动，又好了。而两次启动命令唯一的差别就是前一次启动使用的是mysqld，后一次启动使用的是mysqld_safe，而且多带了一个--user参数。
以上就是恢复mysql主从数据一致性的具体实现方法。