问题说明

在处理主从问题时，发现级联从库中 C 库的延迟远小于 B 库的延迟，而通常情况下 C 库的延迟应该更大。本文探讨了级联从库 C 库延迟计算的机制。

延迟计算

一般情况下，延迟计算公式为： C 库当前时间 - (主库执行命令时间 + B 库执行 query 事件时的延迟时间) - 主从服务器时间差

B 库的 exectime

在 B 库中，query 事件中的 exectime 是 B 库当前时间减去主库执行命令时的start_time，即 B 库在执行 query 事件时的延迟时间。

示例

观察 B 库中的 exectime 可以验证这一现象。

主库 A

at109723051815:50:04
serverid333900
end_log_pos1174
CRC320xab4d2adc
Querythread_id=4
exec_time=0
error_code=0
SETTIMESTAMP=1684396204/!/;
  

从库 B

at106923051815:50:04
serverid333900
end_log_pos1132
CRC320x483e49b5
Querythread_id=4
exec_time=48
erro
  

从示例中可以看到，B 库的 exectime 为 48，即 B 库在执行 query 事件时的延迟时间。

总结

级联从库 C 库的延迟计算公式为： C 库当前时间 - (主库执行命令时间 + B 库执行 query 事件时的延迟时间) - 主从服务器时间差 B 库的 exectime 为 B 库在执行 query 事件时的延迟时间 在时钟同步的情况下，这一机制可以准确地计算级联从库的延迟。

---

如何解决mysql主从延迟

通常少量延迟不是问题。 如果要做到完全同步，对主数据库性能势必有影响。 只要保证从数据库是主数据库在某个时间点的快照就成了。 如果要更具体分析，需要详细描述你的应用场景

mysql slave 备库延迟是怎么得到的

mysql的replication中有2个比较重要的class：Master_info(rpl_mi.h), Relay_log_info(rpl_rli.h)，他们分别对应于master,info文件和文件；很显然，Master_info是io_thread需要的，Relay_log_info是sql_thread需要的。Master_info中有一个变量 clock_diff_with_master，这个值记录着mysql的主库和备库的时间差，可以理解为主备的主机时间差。clock_diff_with_master变量的定义如下：

Cpp代码

Thedifferenceinsecondsbetweentheclockofthemasterandtheclockof

theslave(second-first)<0or>0.

clock_diff_with_masteriscomputedwhentheI/Othreadstarts;forthisthe

I/OthreaddoesaSELECTUNIX_TIMESTAMP()onthemaster.

howlatetheslaveiscomparedtothemasteriscomputedlikethis:

clock_of_slave-last_timestamp_executed_by_SQL_thread-clock_diff_with_master

longclock_diff_with_master;

这个变量的注释直接提到了Seconds_Behind_Master的计算方法：clock_of_slave - last_timestamp_executed_by_SQL_thread - clock_diff_with_master。clock_of_slave是slave的当前时间--执行show slave status的当前时间。

先看一下clock_diff_with_master的计算：()。执行”start slave;“/“start slave io_thread;”后，会执行start_slave_threads来启动io thread，io thread启动后首先做的就是获取主库的mysql版本和主库的当前时间(mysql_real_query(mysql, STRING_WITH_LEN(SELECT UNIX_TIMESTAMP())))，获取到主库的当前时间后，用备库的当前时间减去主库的时间，得到clock_diff_with_master。

具体的逻辑则是，sql thread启动后，读取relaylog(netxt_event())，apply & update pos(apply_event_and_update_pos())，update_pos的时候判断是否执行到了事务的结束位置，如果执行到了，则调用stmt_done()，stmt_done()会将last_master_timestamp更新为最近一次event的创建时间(event_creation_time)。因此如果在主备基本无延迟的时候，主库执行了一个大事务，你会发现备库延迟突然很大，然后又没了，延迟跳跃。