Mysql 主从间延迟

首先需要知道在网络情况良好的情况下，主从之间的延迟主要产生于从库根据消费 relay log 的时间。

主从间的延迟是 seconds_behind_master。

主从延迟的主要原因可能如下:

  • 主库机器配置高于从库机器
    由于从库有时不需要被请求，于是就用稍微差一点的机器部署，但是更新的 IOPS 是相同的，所以从库可能跟不上主库的更新速度。这种情况下一般会给从库设置 非双1 (简单理解就是多个事务一起攒到内存中再把内存同步到硬盘)，现在主从间可能发生切换，所以这种主机配置高于从机的情况可能比较少了。
  • 从库压力过大
    由于主库用于写操作，从库理所应当的用于读操作，有些在主库上不敢进行的占用大量资源的语句可能在从库上运行，此时大量读操作抢占了 CPU 资源，影响了同步速度，从而导致了主从间的延迟。这种情况一般通过一主多从来分担压力。
  • 大事务
    一条事务在主库上跑了很久，来到从库同样需要很久的时间。所以一般我们要减少大事务，比如一次 delete 大量的数据就是比较常见的大事务，我们需要将这些删除分批定量。

主从切换策略：

  • 可靠性优先
  1. 判断备库 B 现在的 seconds_behind_master，如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；
  2. 把主库 A 改成只读状态，即把 readonly 设置为 true；
  3. 判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
  4. 把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
  5. 把业务请求切到备库 B。

由于第2步到第5步，数据库可能出现一段时间不可以，所以要进行第1步来尽量减少不可用的时间。

  • 可用性优先
  1. 把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
  2. 把业务请求切到备库 B。

直接转换可能会导致数据不一致

根据业务场景的不同需要采用不同的策略