读写分离有那些坑?
前言
读写分离主要是一主多从,从库承担读请求。由于同步时间不一致,导致的过期读。
读写分离有那些坑
- 前言
- 那么有那些解决方案呢
那么有那些解决方案呢
- 在从库上的读,默认都sleep1秒,默认一秒内基本都同步完成。缺点:不太靠谱
- 对请求分类,对于要求读一致的请求强制走主库。缺点:有些业务不适用
- 执行查看主库和从库之间是否有未同步完成的命令只有在没有差距的时候才在从库查询 。缺点:高并发下可能永远跟不上,还有一种情况就是主库和从库是同步的,但是新写入的事务还有没有传递给从库,就发起了对从库的查询
- semi-sycn 半同步,解决上面的问题,主库同步给从库之后,从库返回一个ack之后,主库才会给客户端返回成功。一主多从的情况下不适用
5.等主库点位 - 等GTID方案
5 6通过命令 告诉从库 执行到那些事务之后就可以查询,同时约定过期时间
对于GTID ([gtid] ,1) 1表示最多等1秒 返回0则在从库上执行,返回1则去主库上执行