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

同步延迟

  • 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
    数据同步延迟原因及主备切换策略_第1张图片

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

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

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

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

你可能感兴趣的:(mysql,同步延迟,主备延迟原因,主备切换策略)