MySQL 关于slave端Retrieved_Gtid_Set的读取改进初探

本文为以后学习SLAVE做一个记录不保证正确性。因为算法没看懂。

今天朋友问我这样一个问题@K.I.S.S，在官方文档中有这样一段描述：

问为什么要减去last_received_GTID。

对于这个问题我先查看了一下这个bug到底修复了什么问题如下：

大概就是说对于某些I/O线程并没有完整传输的Gtid事物记录到了RETRIEVED_GTID_SET中这会导致比较严重问题，因为某些监控工具根据这个来判断是否切换之类的，因此我们加入了一个事物边界分析器来判断事物是否完整传输，如果完整传输才记录到RETRIEVED_GTID_SET中这是5.7.5过后加入的。总的说来为了进行两个问题的修复：

1、最后一个gtid 事物是否完整。

2、跨越多个relay log的binlog 得到正确的gtid集合。

其实修改得非常多，不一一列举，有兴趣可以自己看看commit 9dab9dad975d09b8f37f33bf3c522d36fdf1d0f9，这里列举几个我看了的地方。

其实这一块也说明了解决的什么问题，我们发现一个事物的binlog event 在relay log中是可以跨文件的。而在bin log中是不能跨文件的。仅仅判断最后一个gtid priv event 是不正确的。因此需要这样修改。

这个类是完全新加入的，这里是其中的一些状态：

这个函数是完全新加入的就是为了完成所说的功能，在read_gtids_and_update_trx_parser_from_relaylog中我看到对文件所有event进行了读取，并且用switch进行了不同event类型的处理，但是具体没有细看。但是最后看到对于对于是否加入retrieve gtid的判断如下：

实际上就在现在看来应该就是读取 relay_log的最后一个gtid事物(gtid event或者gtid priv event)同时需要判断此gtid事物是否完整。对于官方文档给出的UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)，个人觉得这里的 last_received_GTID应该是经过判断的，如果完整则不减，如果不完整则减去。

作者微信：