MySQL主从同步遇到的坑（多数据源切换）

灰太狼 2022-05-14 08:37 287阅读 0赞

question: （多数据源切换）测试环境neza 注册用户回调我们接口写app\_member 表的时候,发现从库里面有数据，主库里面没有，后来发现是因为加了事物的原因，@Transactional。 写入时数据源切换有问题。==》解决将写库写死成master，读的时候切换多数据源。

网上搜了下可能导致主从不同步的原因，转载自：[https://blog.csdn.net/skymouse2002/article/details/80605354][https_blog.csdn.net_skymouse2002_article_details_80605354]

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.主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点  
预防措施：  
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.必须引定期的数据校验机制

# 监控mysql主从同步状态是否异常，如果异常，则发生短信或邮寄给管理员：[https://www.cnblogs.com/liuyansheng/p/8056268.html][https_www.cnblogs.com_liuyansheng_p_8056268.html] #

[https_blog.csdn.net_skymouse2002_article_details_80605354]: https://blog.csdn.net/skymouse2002/article/details/80605354
[https_www.cnblogs.com_liuyansheng_p_8056268.html]: https://www.cnblogs.com/liuyansheng/p/8056268.html