25 | MySQL是怎么保证高可用的？

主备延迟

“同步延迟”，与数据同步有关的时间点主要包括以下三个：

1. 主库A执行完一个事务，写入binlog，把这个时刻记为T1；
2. 之后传给备库B，我们把备库B接收完这个binlog的时刻记为T2；
3. 备库B执行完这个事务，这个时刻记为T3。

主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。

备库上执行show slave status命令，返回结果会显示seconds_behind_master（其实就是T3-T1），表示当前备库延迟了多少秒。

网络正常的时候，日志从主库传给备库所需的时间是很短的，即T2-T1的值是非常小的。也就是说，网络正常的情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。

所以说，主备延迟最直接的表现是备库消费中转日志（relay log）的速度，比主库生产binlog的速度要慢。

主备延迟的来源

有些部署条件下，备库所在机器的性能要比主库所在机器的性能差。（现在这种部署比较少了）

备库压力大。

一般可以这么处理：

1. 一主多从。除了备库外，多接几个从库，分担读的压力。
2. 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。

大事务

如果一个主库上的语句执行10分钟，那么这个事务很可能会导致从库延迟10分钟。

比如，不要一次性的用delete语句删除太多数据。

比如，一些归档类数据，平时没有注意删除历史数据，等到空间快满了，业务开发人员要一次性删除大量历史数据。同时，又因为要避免在高峰期操作会影响业务，所以会在晚上执行这些大量数据的删除操作。（应该要控制每个事物删除的数据量，分多次删除）。

另一种大事务，就是大表DDL

计划内的DDL，建议使用gh-ost方案。

备库并行复制能力

可靠性优先策略

 

可用性优先策略

 

上一篇：24 | MySQL是怎么保证主备一致的？

下一篇：26 | 备库为什么会延迟好几个小时