高性能mysql上说,seconds_behind_master这个值就是从服务器在事件开始执行时的系统时间戳与binlog日志中的事件的时间戳相对比得到的。
果真如此吗?
下面这个测试证明这句话是错误的!
主库对一个上千万行数据的表执行update table t set name='xxx',假设00分00秒开始执行,50秒后执行完毕。此时主库记录的binlog中的时间是00分00秒(记录的是事件开始的时间),而从库在00分50秒时拿的binlog并执行时seconds_behind_master显示的却是0秒、1秒、2秒,依次往上涨直到从库执行完毕。
结论一:从库的seconds_behind_master并不是与binlog中的时间戳(此例中是00分00秒)相比较。在此例中这个值看着好像是指io线程拿到事件的时间和sql线程执行这个事件时间差,而参考手册上就是这么说的,见下。
参考手册上说,seconds_behind_master测量从属服务器SQL线程和从属服务器I/O线程之间的时间差距,单位以秒计。本字段是从属服务器“落后”多少的一个指示。
果真如此吗?是从服务器的两个线程的对比吗?
下面这个测试证明这句话是错的!
从库中断复制stop slave,3天后开启(正好在公司环境中发生过)。此时从库的IO线程去读取binlog并且sql线程去执行,假设网络没有延迟,按参考手册上的说法,seconds_behind_master应该指io线程拿到事件的时间和这个事件执行的的时间的差值。但实际上却发现,从库的seconds_behind_master上来就是3天左右,即从库中断的时间。随着从库渐渐的追赶主库,seconds_behind_master越来越小,直到追赶上之后变为0。即seconds_behind_master是和主库相关联的。
结论二:从库的seconds_behind_master并不是从库的io和sql线程之前的比较,而是与主库的某个时间比较。
结论二说明seconds_behind_master是与主库的某个时间相比较得到的;结论一说明并不是与主库的binlog中的时间做比较得到的。
根据这两个结论,个人判断seconds_behind_master是事件在从库执行的时间与这个事件在主库提交时的时间来比较。而binlog中的时间是事务开始的时间而不是提交时间。所以最后的问题是:这个事务提交时间在哪里?从库怎么知道的?
希望有大牛能看到,一起探讨。