共计 1516 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章给大家分享的是有关 MySQL 主从复制不一致的情况有哪些的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
1. 网络的延迟
由于 mysql 主从复制是基于 binlog 的一种异步复制，通过网络传送 binlog 文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
2. 主从两台机器的负载不一致
由于 mysql 主从复制是主数据库上面启动 1 个 io 线程，而从上面启动 1 个 sql 线程和 1 个 io 线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。
3.max_allowed_packet 设置不一致
主数据库上面设置的 max_allowed_packet 比从数据库大，当一个大的 sql 语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。
4.key 自增键开始的键值跟自增步长设置不一致引起的主从不一致。
5.mysql 异常宕机情况下，如果未设置 sync_binlog= 1 或者 innodb_flush_log_at_trx_commit= 1 很有可能出现 binlog 或者 relaylog 文件出现损坏，导致主从不一致。
6.mysql 本身的 bug 引起的主从不同步。
7. 版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能。
以上就是常见的一些主从不同步的情况。或许还有其他的一些不同步的情况，请说出你所遇到的主从不一致的情况。
基于以上情况，先保证 max_allowed_packet、自增键开始点和增长点设置一致，再者牺牲部分性能在主上面开启 sync_binlog，对于采用 innodb 的库，推荐配置下面的内容：
1)、innodb_flush_logs_at_trx_commit = 1
2)、innodb-support_xa = 1 # Mysql 5.0 以上
3)、innodb_safe_binlog # Mysql 4.0
同时在从数据库上面推荐加入下面两个参数：
1)、skip_slave_start
2)、read_only
8. 主库的从库太多，导致复制延迟
从库数据以 3 - 5 个为宜，要复制的从节点数量过多，会导致复制延迟
9. 从库硬件比主库差，导致复制延迟
查看 Master 和 Slave 的系统配置，可能会因为机器配置不当，包括磁盘 I /O、CPU、内存等各方面因素造成复制的延迟。一般发生在高并发大数据量写入场景中
10. 慢 SQL 语句过多
假如一条 SQL 语句执行时间是 20 秒，那么从执行完毕到从库上能查到数据至少需要 20 秒，这样就延迟 20 秒了。
一般要把 SQL 语句的优化作为常规工作不断地进行监控和优化，如果单个 SQL 的写入时间长，可以修改后分多次写入。通过查看慢查询日志或 show full processlist 命令，找出执行时间长的查询语句或大的事务
11. 主从复制的设计问题
例如主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。更高版本的 Mysql 可以支持多线程复制，门户网站则会开发自己的多线程同步功能。
12. 主从库之间的网络延迟
主从库的网卡、网线、交换机等网络设备都可能成为复制的瓶颈，导致复制延迟。另外，跨公网的主从复制很容易导致主从复制延迟
13. 主库读写压力大，导致复制延迟
架构的前端要加 buffer 及缓存层
感谢各位的阅读！关于“MySQL 主从复制不一致的情况有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
