数据同步延迟原因及主备切换策略

同步延迟

• t1为主库a完成事务,写完binlog的时间
• t2为备库b完成从a传输过来binlog的时间
• t3为备库执行完binlog的时间
• t3-t1就是备库和主库之间的延迟时间,在备库执行命令show slave status,会显示seconds_behind_master,就是延迟几秒

主备延迟的原因

• 备库所在的服务器比主库的服务器性能来的差,但是他们写入的文件是一样多的,所以尽量保证主备性能一致
• 备库压力大,有些读操作在备库上执行,没有优化,直接大批量读取数据,导致io飙升,从而主备延迟,解决方法有多备几个从库
• 大事务的操作,比如大批量的删除修改数据,尽量放在晚上执行这种耗性能的操作

主备切换的策略–可靠性优先策略

• 判断备库b的second_behind_master是否小于5,小于执行下一步,否则循环
• 把主库a设置为只读,readonly设置为true
• 判断备库b的second_behind_master到0为止
• 把备库b的readonly设置为false,也就是可读写
• 把业务切到备库b
  

主备切换的策略-- 可用性优先策略

• 直接把上面45操作放在前面,能够有效的保证可用性,但是有可能数据部分不一致

• 在版本5.6之前,mysql只支持单线程复制,如果主库tps,并发高的时候,主备延迟就会很严重, 所以基本在备库执行rely log的时候用多线程的话,就需要满足一下两个条件

  • 不能造成更新覆盖,所以更新同一行的两个事务,要分发给同一个worker中
  • 同一个事务不能拆开,必须放在同一个worker中