目录
主备延迟
主备延迟的来源
有些部署条件下，备库所在机器的性能要比主库所在的机器性能差
第二种常见的可能了，即备库的压力大
第三种可能了，即大事务
另一种典型的大事务场景，就是大表DDL
主备切换
主备延迟
主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。
数据同步有关的时间点主要包括以下三个：
- 主库A执行完成一个事务，写入binlog，我们把这个时刻记为T1;
- 之后传给备库B，我们把备库B接收完这个binlog的时刻记为T2;
- 备库B执行完成这个事务，我们把这个时刻记为T3。
所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。
在备库上执行show slave status命令，它的返回结果里面会显示seconds_behind_master，用于表示当前备库延迟了多少秒。
seconds_behind_master的计算方法是这样的：
- 每个事务的binlog 里面都有一个时间字段，用于记录主库上写入的时间；
- 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到seconds_behind_master。
可以看到，其实seconds_behind_master这个参数计算的就是T3-T1。所以，我们可以用seconds_behind_master来作为主备延迟的值，这个值的时间精度是秒。
主备延迟的来源
有些部署条件下，备库所在机器的性能要比主库所在的机器性能差
当然，这种部署现在比较少了。因为主备可能发生切换，备库随时可能变成主库，所以主备库选用相同规格的机器，并且做对称部署，是现在比较常见的情况。
第二种常见的可能了，即备库的压力大
一般的想法是，主库既然提供了写能力，那么备库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。
这种情况，我们一般可以这么处理：
- 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
- 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
第三种可能了，即大事务
大事务这种情况很好理解。因为主库上必须等事务执行完成才会写入binlog，再传给备库。所以，如果一个主库上的语句执行10分钟，那这个事务很可能就会导致从库延迟10分钟。
不知道你所在公司的DBA有没有跟你这么说过：不要一次性地用delete语句删除太多数据。其实，这就是一个典型的大事务场景。
另一种典型的大事务场景，就是大表DDL
主备切换
在图1的双M结构下，从状态1到状态2切换的详细过程是这样的：
- 判断备库B现在的seconds_behind_master，如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；
- 把主库A改成只读状态，即把readonly设置为true；
- 判断备库B的seconds_behind_master的值，直到这个值变成0为止；
- 把备库B改成可读写状态，也就是把readonly 设置为false；
- 把业务请求切到备库B。
这个切换流程，一般是由专门的HA系统来完成的，我们暂时称之为可靠性优先流程
