选项如下：
首先，看看主的最新位置，作为奴隶复制的起点。
这种理念体现在过去是没有跟上现在既往不咎，一致就可以了。看来，这种想法是与原来的恢复从主从库数据的一致性的意图不一致，但这种方法简单有效，可用于测试环境与历史数据要求低。
二是严格恢复主、副库数据的一致性。
这里有两种思考方式：
1。备份数据，在从库中恢复时，基于历史数据同步的一致性，但这种方法相当麻烦，必须在主库中执行锁表操作，防止客户端进行数据更新操作，而且在数据量大的情况下备份是一件费时的事情。实际上，这种方法在实际生产环境中也很少使用。
2。跳过相关错误
事实上，这不是一个非常严格的生活，准备说，是跳过相关的事务。在我今天的例子中，跳过是由于违反主键约束而失败的INSERT语句。
如何跳过相关事务
1。从服务停止
二，设置全局sql_slave_skip_counter = 1；
三，开放奴隶服务。
这是一个跳过这里的事务。当然，你可以跳过很多事情，但是要小心。毕竟，你不知道该跳过什么。
建议：上述步骤可以重复，并且可以从库中不同步地对语句进行仔细检查。在某些情况下，阻止库中的事务太多是有效率的。
在主库日志交易可以分析确定适当的值的sql_slave_skip_counter.the具体步骤如下：
1。在存储库中执行显示奴隶状态，并确认以下两个参数
根据以上两个参数的值，查看当前阻碍库中的复制和主库中的后续事务的事务。
MySQL >显示binlog in'mysql-bin 000217'from 673146776事件；
这是所有交易查看交易ID是673146776后的日志文件mysql-bin.000217。
当然，表现binlog事件的使用相当灵活，以下都是有可能的。
MySQL >显示binlog事件in'mysql-bin。000217'from 673146776 G
MySQL >显示binlog事件in'mysql-bin 000217'from 673146776上限10；
它也可以通过在宿主环境mysqlbinlog命令查看
复制代码如下：# mysqlbinlog mysql-bin.000217——起始位置= 673146776
如何查询语句的执行
在跳从图书馆相关交易和重新启动的奴隶，slave_io_running，slave_sql_running两项都显示是的，但seconds_behind_master没有立即下降，但增长缓慢。
在这个时候，通过SHOW PROCESSLIST语句看到线程的执行，这是发现的第一个语句执行太长，状态栏显示发送数据，在发送数据的意义，官方的描述如下：
可以看出，该语句涉及大量磁盘读取。
为了进一步分析语句的耗时分布，可以设置分析变量：
首先，在查询开始之前，设置设置；
二，该语句执行后，看到声明通过显示配置文件的query_id。
三、看到声明通过queryquery_id显示剖面的具体执行。
还发现这个语句在发送数据阶段花费太长时间。
总结：
1。在停止实施停止挂奴隶，奴隶是活的，网上查询相关信息，有可能是这里长的SQL或锁定在相关的SQL执行的奴隶，除了显示列表，显示奴隶的身份，最好不要做奴隶停止奴隶相关的命令。所以你怎么解决的问题吗线程等待锁的slavesql结束，或数据库重新启动。我选择了后者。
2、在重新启动数据库的过程中，有一个小插曲。执行启动奴隶的命令时，报以下错误：错误1872（hy000）：从初始化失败中继日志信息和日志，很多互联网上的信息推荐配置主从集群，因此回到程序的选择开始。奇怪的是，我关从图书馆，重新启动，并确定。两启动命令的唯一区别是，mysqld被用在前引导，和mysqld_safe进行最后的靴子，和一个用户参数了。
以上是恢复mysql主从数据一致性的具体实现方法，希望能对大家有所帮助。
