什么情况下MySQL主从复制会出现不一致

一、MySQL主从复制什么原因会造成不一致

导致主从不一致的原因主要有：

1、人为原因导致从库与主库数据不一致（从库写入）

2、主从复制过程中，主库异常宕机

3、设置了ignore/do/rewrite等replication等规则

4、binlog非row格式

5、异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。

6、从库中断很久，binlog应用不连续，监控并及时修复主从

7、从库启用了诸如存储过程，从库禁用存储过程等

8、数据库大小版本/分支版本导致数据不一致？，主从版本统一

9、备份的时候没有指定参数 例如mysqldump --master-data=2 等

10、主从sql_mode 不一致

11、一主二从环境，二从的server id一致

12、MySQL自增列 主从不一致

13、主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点

14、采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库

15、启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制

二、如何预防及解决？

预防和解决的方案有：

1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=1

2、slave:master_info_repository=“TABLE”&relay_log_info_repository=“TABLE”&relay_log_recovery=1

3、设置从库库为只读模式

4、可以使用5.7增强半同步避免数据丢失等

5、binlog row格式

6、必须引定期的数据校验机制

7、当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~

8、mha在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha本身机制导致这个问题）

三、MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中，该如何选择？

几种复制场景都有存在的价值。下面分别描述一下：

1.从成熟度上来选择，推荐：异步复制(GTID+ROW)

2.从数据安全及更高性能上选择：增强半同步 （在这个结构下也可以把innodb_flush_log_trx_commit调整到非1， 从而获得更好的性能)

3.对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景，可以使用MGR

1.异步复制，相对来讲非常成熟，对于环境运维也比较容易上手

2.增强半同步复制，可以安全的保证数据传输到从库上，对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点，而且在一致性和性能有较高的提升，但对运维上有一定的要求

3.MGR组复制。相对增强半同步复制，MGR更能确保数据的一致性，事务的提交，必须经过组内大多数节点（n/2+1）决议并通过，才能得以提交。MGR架构对运维难度要更高，不过它也更完美

总的来讲，从技术实现上来看：MGR> 增强半同步>异步复制。

本文来自博客园，作者：IT随笔，转载请注明原文链接：http://www.cnblogs.com/binyue/p/17411893.html