Mysql 主从间延迟
首先需要知道在网络情况良好的情况下,主从之间的延迟主要产生于从库根据消费 relay log 的时间。
主从间的延迟是 seconds_behind_master。
主从延迟的主要原因可能如下:
-
主库机器配置高于从库机器
由于从库有时不需要被请求,于是就用稍微差一点的机器部署,但是更新的 IOPS 是相同的,所以从库可能跟不上主库的更新速度。这种情况下一般会给从库设置
非双1
(简单理解就是多个事务一起攒到内存中再把内存同步到硬盘),现在主从间可能发生切换,所以这种主机配置高于从机的情况可能比较少了。 -
从库压力过大
由于主库用于写操作,从库理所应当的用于读操作,有些在主库上不敢进行的占用大量资源的语句可能在从库上运行,此时大量读操作抢占了 CPU 资源,影响了同步速度,从而导致了主从间的延迟。这种情况一般通过一主多从来分担压力。
-
大事务
一条事务在主库上跑了很久,来到从库同样需要很久的时间。所以一般我们要减少大事务,比如一次 delete 大量的数据就是比较常见的大事务,我们需要将这些删除分批定量。
主从切换策略:
-
可靠性优先
- 判断备库 B 现在的 seconds_behind_master,如果小于某个值(比如 5 秒)继续下一步,否则持续重试这一步;
- 把主库 A 改成只读状态,即把 readonly 设置为 true;
- 判断备库 B 的 seconds_behind_master 的值,直到这个值变成 0 为止;
- 把备库 B 改成可读写状态,也就是把 readonly 设置为 false;
- 把业务请求切到备库 B。
由于第2步到第5步,数据库可能出现一段时间不可以,所以要进行第1步来尽量减少不可用的时间。
-
可用性优先
- 把备库 B 改成可读写状态,也就是把 readonly 设置为 false;
- 把业务请求切到备库 B。
直接转换可能会导致数据不一致
根据业务场景的不同需要采用不同的策略