MySQL中slave端Retrieved_Gtid_Set读取改进的示例分析

小编给大家分享一下MySQL中slave端Retrieved_Gtid_Set读取改进的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
今天朋友问我这样一个问题@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，这里列举几个我看了的地方。

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

2、其次加入了边界分析器Transaction_boundary_parser类
这个类是完全新加入的，这里是其中的一些状态：

3、read_gtids_and_update_trx_parser_from_relaylog函数新增
这个函数是完全新加入的就是为了完成所说的功能，在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应该是经过判断的，如果完整则不减，如果不完整则免费主机域名减去。以上是“MySQL中slave端Retrieved_Gtid_Set读取改进的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云技术行业资讯频道！

相关推荐: PostgreSQL HA环境分析

本篇内容介绍了“PostgreSQL HA环境分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！基于streaming replication搭建的Postgr…