Mysql在切换主从的时候,保业务还是保数据?

目的

备库作为主,主库作为备

问题

数据库不是静态的,切换的时候从库还有没应用完的中继日志,这里是保业务还是保数据?
切换的时候,主库还在不断的写入数据,从库还没有追上主库。

策略
策略一:可靠性优先策略
假设两个库都是正常运行,没有出现掉线,A主B备,B复制A,B库肯定有seconds_behind_master,这里是表示B落后A多少,小的时候是几秒钟,大的时候是几分钟甚至几十分钟上小时,所以在切换之前检查B检查A是否太多,假如太多那么不能切换!为什么不能?比如B落后A5秒内,这个时候切换比较合适,比如B落后A三秒,也就是B还有3秒的中继日志没重放,这个时候A开启只读 readonly=true,那么A库只读,B库也一般只读,AB都是只读,整个系统是只可读不可写,那么只能查询影响业务,那么A就不再产生Binlog了,B那么就不再接收新的中继日志了,那么B落后A越来越少,B直接网上追,那么几秒钟之后就追上A了,那么AB一致,这时候检查一下B库是否追上,B的seconds_behind_master=0,这个时候B库关闭只读readonly=false,B停止复制A库,A开始复制B。
优势:保障中间数据不会丢失,比如从写A开始,A又不让写,代表客户端写不进A来,客户端就会等着,数据不会丢。问题是有几秒两个库都不可写,只能读,所以影响业务。也就是数据可靠,业务不可控。
如果B落后A一分钟,一分钟不可写,那么很大程度影响业务。假如B一直落后A十分钟,那么这种可以考虑开启并行复制策略,让B抓紧追,等B追上来再切换。

策略二:可用性优先策略
取消等待数据一致的过程,取消B等待A。直接A开只读,B关只读,强行A复制B,B库停止复制A。
优点:系统没有不可写的时间。
缺点:有数据不可靠性,因为B落后A,B还有没有应用的中继日志,造成数据不一致的错误。比如客户端刚在A插入一条数据,这时候切换了主从,B还没来得及应用A的日志,这时候B就要改这条数据,但B没有这条数据,因为B还没来得及跑中继日志,还没追上,这时候改一个不存在的数据会造成数据不一致。
但是这种策略适合一直往里写数据,不会改,而且没有复杂业务处理造成数据不一致。

如果事务比较多的业务场景,尽量使用第一种可靠性优先策略

 

posted @   温柔的风  阅读(253)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!
历史上的今天:
2020-11-02 Golang协程调度原理( G、M、P)
2018-11-02 PHP调试封装类
2018-11-02 Yii笔记:打印sql、Form表单、时间插件、Mysql的 FIND_IN_SET函数使用、是否是post/ajax请求
点击右上角即可分享
微信分享提示