- 深入理解MySQL主从原理
- 高鹏
- 409字
- 2025-02-21 07:58:38
1.1.6 gtid_executed表的作用
官方文档这样描述gtid_executed表:

也就是说,gtid_executed表是GTID持久化的一个介质。实例重启后所有的内存信息都会丢失,GTID模块初始化需要读取GTID持久化介质。
可以发现,gtid_executed表是InnoDB表,建表语句如下,并且可以手动更改它,但是除非是测试,否则千万不要修改它。

除了gtid_executed表,还有一个GTID持久化的介质,那就是binary log中的GTID_EVENT。
既然有了 binary log 中的GTID_EVENT 进行 GTID 的持久化,为什么还需要gtid_executed表呢?笔者认为,这是MySQL 5.7.5之后的一个优化,可以反过来思考,在MySQL 5.6 中,如果使用 GTID 做从库,那么从库必须开启 binary log,并且设置参数 log_slave_updates=ture,因为从库执行过的GTID操作都需要保留在binary log中,所以当GTID模块初始化的时候会读取它获取正确的GTID SET。接下来,看一段MySQL 5.6官方文档对于搭建GTID从库的说明。


然而,开启binary log的同时设置参数log_slave_updates=ture必然会造成一个问题。很多时候,从库是不需要做级联的,设置参数log_slave_updates=ture会造成额外的空间和性能开销。因此需要另外一种 GTID 持久化介质,而并不是 binary log 中的 GTID_EVENT,gtid_executed表正是这样一种GTID持久化的介质。在1.3节会看到它的读取过程。