主备延迟
“同步延迟”,与数据同步有关的时间点主要包括以下三个:
- 主库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方案。
备库并行复制能力
可靠性优先策略
可用性优先策略