mysql复制系列7-复制延迟计算

我们在主从复制中最常遇到我的问题就是复制延迟的问题，那究竟复制延迟是怎么计算的呢？

复制延迟的准确定义应该是：同一个事务从主节点提交事务到从节点提交事务的时间间隔通常称之为复制延迟包括 包括事务被传输到从库的时间以及在从库应用的时间

我们经常使用的show slave status 中的Seconds_Behind_Master 是如何计算的

Seconds_Behind_Master计算公式：

clock_of_slave - last_timestamp_executed_by_SQL_thread - clock_diff_with_master

该公式含义为 "从库的当前系统（主机）时间 - 从库 SQL 线程正在执行的event的时间戳 - 主从库的系统（主机）之间的时间差"主从服务之间时间差只在io_thread启动时计算一次，以后复用这个值，所以io_thread线程启动后主从服务时间逐渐不一致，会导致看到主从时间延迟不准确的情况

Seconds_Behind_Master 计算复制延迟需要注意的地方：

1.当复制线程启动后，修改操作系统时间会导致计算出得复制延迟时间不准（重启io_thread可以修正）

2.如果io线程和sql线程同时为YES，且sql线程没有做任何事，此时直接判定复制延迟为0

3.如果sql线程为YES 而io线程为NO 且sql线程未应用完中继日志则会根据公式计算延迟，如果sql线程回放完中继日志，则直接判定延迟结果null

4.任何时候sql线程不为YES,则直接判定复制延迟为null

5.当sql线程回放大事务时，日志中事务的时间戳是一样的，因为事务是需要很长时间回放完，所以计算出来的延迟非常大，当应用完后延迟可能会突然变为0

从Mysql8.0 开始提供如下两个event可以用计算主从复制延迟

original_commit_timestamp： 主库节点事务成功commit(写入binlog)的毫秒数 unix时间

immediate_commit_timestamp，从库应用事务并成功commit的毫秒数（基于unix epoch time：1970-01-01T00:00:00Z算起）

同一事务在主从binlog日志中的original_commit_timestamp 是一样的，immediate_commit_timestamp是事务在slave上成功提交的时间所以在操作系统时间一致的情况下，主从延迟就是 immediate_commit_timestamp 减去original_commit_timestamp

Mysql8.0计算复制延迟更准确，特别是在级联复制的环境下计算复制延迟

可以通过相关的表字段计算出复制延迟如replication_applier_status_by_coordinator，replication_applier_status_by_work

另外还可以使用 percona的pt-heartbeat来监控主从延迟