主备延迟
与数据同步有关的时间点主要包括以下三个：主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;备库 B 执行完成这个事务，我们把这个时刻记为 T3。所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。可以通过show slave status的seconds_behind_master查看备库延迟了多少秒。
主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。系统时间没有影响。
主备延迟的来源
1.主备机器性能不一致，少见
2.备库压力大，轻视导致备库上的查询耗费了大量的 CPU 资源。一主多从来分担读压力。
3.大事务，不要一次性地用 delete 语句删除太多数据，这是一个大事务。还有一种是大表DDL。
可靠性优先策略
双 M 结构下，主备切换的详细过程是这样的：
1.判断备库 B 现在的 seconds_behind_master，如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；
2.把主库 A 改成只读状态，即把 readonly 设置为 true；
3.判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
4.把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
5.把业务请求切到备库 B。
这个切换流程，一般是由专门的 HA 系统来完成的。
可用性优先策略
如果强行把步骤 4、5 调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库 B，并且让备库 B 可以读写，那么系统几乎就没有不可用时间了。但会丢数据，一般数据可靠性要高于可用性的，故不推荐。
参考资料：丁奇，MySQL实战45讲
部分内容来自网络，如有侵权请联系作者删除。
