读写分离会带来的问题之前的文章，我也反复强调过，任何的架构、软件、框架、组件...在解决一部分问题的时候，一定会带来其他的问题；读写分离最大的一个问题就是，数据从主复制到从的过程中，可能会存在延迟的，如果客户端在执行完一个读操作后，立刻从存库中查询的话，可能会读取到旧数据的情况（我们不断优化，也只能缩短这个时间，并不能完全消除掉这个时间） 。
那么针对这个问题，有哪些处理方法呢？根据具体场景进行评估，是否可以接收这个延迟（这好像是一句废话，但是大多数业务场景，是可以接收这点儿延迟的）；对于实时性要求很高的场景（查询的数据必须是最新的结果），将这些请求强制路由到主库上；执行完写操作之后，在读操作发生之前，让中间的时间变长（也就是从业务操作角度来做一些控制，不一定操作完了立刻查询）；判断主备无延迟，可以通过判断seconds_behind_master参数、对比GTID、对比位点等方式，判断从数据库是否和主数据库一致 。
今天发生了一件有趣的事情,昨天搭建测试数据库主从读写分离,随便建了个库傻瓜式的密码,今天到公司发现Slave主机数据库没了,多出来一个之前没有,只有一个字段两条数据,翻译一下意思是我的数据库被他们备份了,要我支付比特币购买,否则就把数据放到黑市去出售,搞笑了,表里就一条张三的数据,价值3w? 。
推荐阅读
- 看看坚果的读写速度
- 小学老师写论文发表哪些网站,论文发表在哪个数据库平台比较权威
- 一文理解Mysql,MVCC
- 数据库系统工程师,《数据库系统概论》第五版
- mysql读写分离,Mysql读写分离
- 有哪些数据库论文文献,查找并下载外文文献
- 非关系数据库,传统的关系数据库在应付web2
- 果汁分离榨汁机哪个牌子好，渣汁分离榨汁机有什么用
- 嫦娥五号组合体分离,到底是什么状况
- wind数据库免费版,Wind金融数据库