最近遇到一个奇葩的BUG。版本5.7.14，明明主从延迟巨大，但是SBM却显示为0，从库服务器时间没有改动过。
翻了一下BUG，查到如下：
https://bugs.mysql.com/bug.php?id=84415
这个BUG在5.7.22修复。从BUG的描述中我们也能看到这是其实是一个较为严重的BUG。因为很多的监控软件和高可用都以这个值为参考值，如果使用低版本的MTS需要注意了。本来想好好分析下原因，但是发现主从部分忘了很多，很明显不可能又去看流程，这个其实也在所难免，毕竟即便是自己撸的代码时间久了都会忘记，因此注释和笔记变得尤为重要。其次修复一个较为复杂的BUG还是比较难的，首先你要知道代码在描述什么，是什么意思，它的上下文是什么，这就可能直接导致你需要去熟悉某一个模块，这也直接反应出你对某个功能模块的熟悉程度。
于是我看了下以前的笔记和注释，勉强记录如下，
sql线程分发主要流程：
读取event->执行检查点(GAQ出队)->计算last_master_timestamp->分发给worker( GAQ入队 遇到堵塞)
主要问题可能协调线程如果在计算last_master_timestamp的时候GAP队列为空导致计算计算延迟异常，而这个随后分配的时候协调线程遇到了堵塞导致last_master_timestamp不能更新。因此修改GAQ队列为空的情况，转换为直接从sql线程的分配的事务上获取延迟。
- mts_checkpoint_routine函数更改
本函数主要处理检查点，并且使用lwm的信息填充主从计算的last_master_timestamp
//如果GAP队列为空，会更新rli->last_master_timestamp == 0
- rli->reset_notified_checkpoint(cnt, rli->gaq->lwm.ts, need_data_lock);
+ ts= rli->gaq->empty()
+ ? 0
+ : reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts;
+ rli->reset_notified_checkpoint(cnt, ts, need_data_lock, true);
- exec_relay_log_event函数更改
下面就是取SQL协调线程的计算last_master_timestamp的修改exec_relay_log_event函数计算延迟的修改，在分发函数apply_event_and_update_pos之前
//如果rli->last_master_timestamp == 0，则说明GAP队列为空，这里做更改
- if (!(rli->is_parallel_exec() ||
- ev->is_artificial_event() || ev->is_relay_log_event() ||
+ if ((!rli->is_parallel_exec() || rli->last_master_timestamp == 0) && //如果不为MTS或者MTS为的last master timestamp为0
+ !(ev->is_artificial_event() || ev->is_relay_log_event() ||
(ev->common_header->when.tv_sec == 0) ||
ev->get_type_code() == binary_log::FORMAT_DESCRIPTION_EVENT ||
ev->server_id == 0))
因此可能监控的时候我们还需要对执行的position或者GTID进行监控，不要完全相信SBM这个值。
