浅析数据库主从延迟的相关方案

前言

在数据库高可用设计中，我们可能会做主从同步+读写分离，但是在这过程中可能存在主从库数据不一致的情况。

解决方案

一、强制走主库方案

• 把查询请求分为两类：数据更新后，再次查询到的数据不允许延迟的请求、允许延迟的请求
• 让这种不允许延迟的请求强制走主库

二、Sleep方案

更新主库数据之后，在查询请求的时候，sleep一秒

三、判断主备无延迟

数据库中有seconds_behind_master参数，可以通过show slave status命令查看，当为0的时候，代表主备没有延迟。

但该参数的单位是秒，如果想要更加精细化地判断主备是否有延迟，可以通过对比位点：

第一组：Master_Log_File 和 Read_Master_Log_Pos，表示的是读到的主库的最新位点；

第二组：Relay_Master_Log_File 和 Exec_Master_Log_Pos，表示的是备库执行的最新位点。

如果 这两组值完全相同，就表示接收到的日志已经同步完成。

但是需要注意的是 ，这种办法不能完全保证主备没有延迟，因为上面判断主备无延迟，只是从库收到的binlog是OK的，但有一部分日志可能是客户端已经提交确认，但从库还没收到的情况。

四、半同步复制semi-sync

简单来说就是，当客户端提交事务给数据库的时候，主库会把binlog给到从库，只有当从库binlog执行完成，并给数据库ACK了之后，才会给客户端反馈“事务执行完成”。

但是这种方案的弊端是，只对一主一从这种架构成立，当出现多从的时候，只要有一个从库ACK了，就会给客户端反馈事务执行完成。