MySQL主备延迟的原因

在上篇文章中记录了一次由主备延迟导致的relay log打满磁盘的问题，结合林奇大佬的《MySQL是怎么保证高可用的？》，分析一下主备延迟的原因。

主备同步

主库和备库之间的同步流程如图所示：

1. 在备库B 上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。
2. 在备库B 上执行start slave命令，此时备库会启动两个线程，io_thread和 sql_thread。其中io_thread负责与主库建立连接。
3. 主库A校验完用户名、密码后， 开始按照备库B 传过来的位置，从本地读取binlog，发给B。
4. 备库B拿到binlog后，写到本地文件，称为中转日志（relay log）。
5. sql_thread 读取中转日志，解析出日志里的命令，回放执行。
   

主备延迟

与数据同步相关的时间点主要包括以下三个：

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

主备延迟：同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，T3-T1。
可以通过 执行：

SHOW SLAVE STATUS

查看seconds_behind_master,用于表示当前备库延迟了多少秒。

主备延迟的一个直观表现就是：备库中relay log被消费的速度远小于主库生成binlog的速度， 就会导致备库中relay log的积压，最后打满磁盘。

主备延迟的原因

1. 早期，备库所在机器的性能和主库的性能不一致，导致备库处理relay log跟不上主库生成binlog的速度。现在基本主备的机器都一样，而且是对称部署。
2. 备库压力过大， 主库负责写， 备库除了承担读的工作，还会执行一些后台运营的分析语句，但是实际工作中，大家对于主库的使用都很克制， 反而忽视了备库的压力控制，结果就是备库上的资源压力很大，影响了主备同步。
   • 应对措施： 采用一主多从的架构，就是有多个从库分担备库的压力，另外数据库需要定期全量备份数据，从库适合数据备份。
3. 采取了一主多从的架构，还是会出现主备延迟，一般有两大原因：

   • 大事务, 根据同步的流程，主库执行完一个事务花费10分钟，然后再写入binlog，传给备库，备库在此期间只能等待10分钟。典型场景：一次性使用delete语句 删除大量数据。
     下图是产生问题的备库中relay log的大小，基本都是大事务。
     

   • DDL，在DDL期间，在mysql 5.5版本之前会阻塞DML，使用Online DDL也会因为需要扫描原表数据和构建临时文件，都是非常耗时的操作。

总结

为了设计一个高可用的系统, MySQL引入了主备切换的机制，在主库出现问题时可以快速切换到备库提供服务。但是为了维持主备库之间数据的一致性的同步机制，又带来了新的问题，主备延迟。主备延迟带来的后果是多方面的，比如会反过来影响数据的一致性和可用性，relaylog的积压等等问题。