MySQL 8.0新的GTID持久化线程和GTID恢复方式

虽然线程本身很简单，但是涉及到purge线程，事务/UNDO等核心概念。

水平有限，仅供参考。

一、总体变化

我们这里说的GTID持久化线程，就是我们看到的如下：

| thread/innodb/clone_gtid_thread             |         6703 |

其实整个GTID持久化线程，依赖了数据结构Clone_persist_gtid，而它本 身 也是全局变量Clone_Sys中的一个元素而已。 我们后面 再 看其中的重要元素，它在用户线程做innodb成提交的时候起到了作用，同时协调了GTID持久化线程和purge线程，是核心的数据结构。

总的说来就是下面的变化：

• 用户线程提交事务将gtid写入到undo header，并且写入到gtid刷新链表中。

• GTID持久化线程每100毫秒进行gtid flush链表的批量刷新到gtid_executed表中，且GTID持久化线程代替了GTID压缩线程的功能，进行GTID的压缩。

• purge线程不允许清理未写入到gtid_executed表中事务的undo，为恢复提供基础。

• Crash recovery的时候gtid内存值的恢复也会读取undo header，因此不再是5.7的仅仅依赖binlog和gtid executed表。

这样带来的最直观的表现是：

• 5.7中binlog开启的情况下gtid_executed表示binlog切换更新

• 8.0中binlog开启的情况下gtid_executed表是实时（准实时）更新

此外这一块和clone有着紧密的关系，也会后面学习clone plugin提供一个基础。

二、核心数据结构Clone_persist_gtid中的重要元素

元素	解释
静态常量s_time_threshold_ms	硬编码100毫秒，gtid 持久化线程的执行周期
静态常量s_compression_threshold	硬编码50，这个50的单位是gtid持久化线程批量刷gtid_executed表的次数，通常binlog开启就是每50次gtid批量持久化后进行一次gtid_executed表压缩
静态常量s_gtid_threshold	硬编码1024，单位是事务个数，如果用户提交线程发现积压的gtid事务有多于1024个没有写到gtid_executed表，会主动唤醒gtid持久化线程
静态常量s_max_gtid_threshold	硬编码1024*1024，单位是事务个数，如果用户提交线程发现积压的gtid事务有多于1024*1024个没有写到gtid_executed表，会主动等待gitd持久化线程写gtid_executed表
m_gtids[2]	gtid刷新链表，有2个，轮询使用，每批量刷一次gtid到gtid_executed表会切换一次，并且前一个链表清空
原子变量m_active_number	单位是gtid刷新链表切换的次数，主要用确认该刷哪个链表了，代表准备刷入
原子变量m_flush_numbe