主备延迟
“同步延迟”，与数据同步有关的时间点主要包括以下三个：
- 主库A执行完一个事务，写入binlog，把这个时刻记为T1；
- 之后传给备库B，我们把备库B接收完这个binlog的时刻记为T2；
- 备库B执行完这个事务，这个时刻记为T3。
主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。
备库上执行show slave status命令，返回结果会显示seconds_behind_master（其实就是T3-T1），表示当前备库延迟了多少秒。
网络正常的时候，日志从主库传给备库所需的时间是很短的，即T2-T1的值是非常小的。也就是说，网络正常的情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。
所以说，主备延迟最直接的表现是备库消费中转日志（relay log）的速度，比主库生产binlog的速度要慢。
主备延迟的来源
有些部署条件下，备库所在机器的性能要比主库所在机器的性能差。（现在这种部署比较少了）
备库压力大。
一般可以这么处理：
- 一主多从。除了备库外，多接几个从库，分担读的压力。
- 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
大事务
如果一个主库上的语句执行10分钟，那么这个事务很可能会导致从库延迟10分钟。
比如，不要一次性的用delete语句删除太多数据。
比如，一些归档类数据，平时没有注意删除历史数据，等到空间快满了，业务开发人员要一次性删除大量历史数据。同时，又因为要避免在高峰期操作会影响业务，所以会在晚上执行这些大量数据的删除操作。（应该要控制每个事物删除的数据量，分多次删除）。
另一种大事务，就是大表DDL
计划内的DDL，建议使用gh-ost方案。
备库并行复制能力
可靠性优先策略
可用性优先策略
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
