主从延迟

主库A执行完事务，写入binlog，记为时刻 T1。
binlog传给从库B，从库B接收完binlog，记为 时刻T2。
从库B执行完事务，记为时刻T3。
网络正常时，binlog从主库传递到从库的时间是很短的，所以主从延迟需要的来源是 从库接收完binlog到执行完relaylog的时间差。

从主延迟的来源

主要是从库的relaylog执行速度慢于主库的binlog生成速度，可能的原因：

1. 从库的机器性能比主库差。（解决：部署相同性能机器）
2. 由于读写分离、或者运营复杂的查询SQL都在从库执行，导致从库压力大。（解决：一主多从、通过binlog将数据输出到外部大数据系统来支持运营复杂SQL）
3. 大事务导致执行时间很长，会直接造成主从延迟。
   1. 典型场景是一次性delete大量数据。（解决：将大事务分为少量多次执行）
   2. 大表DDL也是大事务场景。（解决：计划内的DDL，建议使用gh-ost方案）

主从切换（双Master架构下）

可靠性优先方案

1. 判断从库B的seconds_behind_master主从延迟时间，如果小于阈值（比如5秒）才执行下一步，否则持续重试。
2. 将主库A改成readonly=true
3. 等待从库B的seconds_behind_master变为0
4. 将从库B的readonly设置为false
5. 业务请求切到从库B

这种方案的孙在系统不可用时间，时长取决于第三步中等待从库B的主从延迟时间变为0。

可用性优先方案（用处较少）

将上面的步骤4和5直接改为首先执行。