之所以把MySQL.GTID_EXECUTED表的作用和PREVIOUS GTID EVENT的改變放到一起進行描述是因為它們后面文章探討的基礎。這部分使用到了我自己使用C語言寫的原生BINLOG解析工具INFOBIN。

一、GTID EVENT

為什么要先描述什么是GTID EVENT呢？因為后面會用到，實際上在其中核心元素就是一個形如：

31704d8a-da74-11e7-b6bf-52540a7d243:100009

的一個GTID 處于整個事務EVENT中的開始，用于描述這個事務的GTID 是多少，當然在5.7中為了支持MTS其中還封裝了LAST_COMMIT/SEQUENCE_NUMBER。那么使用INFOBIN工具查看一個INSERT單條語句完整事務的EVENT包括如下：

>Gtid Event:Pos:234(0Xea) N_pos:299(0X12b) Time:1513135186Event_size:65(bytes) Gtid:31704d8a-da74-11e7-b6bf-52540a7d243:100009last_committed=0sequence_number=1-->Query Event:Pos:299(0X12b) N_Pos:371(0X173) Time:1513135186Event_size:72(bytes) Exe_time:0Use_db:test Statment(35b-trun):BEGIN/*!Trx begin!*/Gno:100009---->MapEvent:Pos371(0X173) N_pos:415(0X19f) Time:1513135186Event_size:44(bytes) TABLE_ID:108DB_NAME:test TABLE_NAME:a Gno:100009------>Insert Event:Pos:415(0X19f) N_pos:455(0X1c7) Time:1513135186Event_size:40(bytes) Dml on table: test.a? table_id:108Gno:100009>Xid Event:Pos:455(0X1c7) N_Pos:486(0X1e6) Time:1513135186Event_size:31(bytes) COMMIT;/*!Trx end*/Gno:100009

當然也可以使用MySQLBINLOG進行分析，只是格式稍微不那么友好。

二、GTID_EXECUTED表的作用

這一部分是重點中的重點，也是我以前一直疑惑的，請大家細細品讀。

官方文檔這樣描述GTID_EXECUTED表

BeginningwithMySQL5.7.5, GTIDs are storedina table named gtid_executed,inthe mysqldatabase. A rowinthistable contains,foreach GTID or setofGTIDs that it represents, the UUIDoftheoriginating server, and the starting and ending transaction IDsofthe set;fora row referencing only asingle GTID, these last two values are the same.

也就是說GTID_EXECUTED表是GTID持久化的一個工具，如前文所描述GTID_STATE中的

GET_EXECUTED_GTIDS/GET_LOST_GTIDS/GET_GTIDS_ONLY_IN_TABLE/GET_PREVIOUS_GTIDS_LOGGED這些數據都是存儲在內存中的，那么在數據庫重啟后需要進行初始化，那么這需要讀取GTID持久化的介質，我們可以發現GTID_EXECUTED是一個

INNODB表建表語句如下，并且我們可以手動更改它，但是千萬不要這么干：

Table: gtid_executedCreate Table: CREATE TABLE`gtid_executed`(`source_uuid`char(36) NOT NULL COMMENT'uuid of the source where the transaction was originally executed.',`interval_start`bigint(20) NOT NULL COMMENT'First number of interval.',`interval_end`bigint(20) NOT NULL COMMENT'Last number of interval.',? PRIMARY KEY (`source_uuid`,`interval_start`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0

那么在5.7.5以前沒有GTID_EXECUTED表不是也沒有問題嗎？其實除了GTID_EXECUTED表以外我們還有一個GTID持久化的介質那就是BINLOG中的GTID EVENT。所以總結一下GTID持久化介質：

GTID_EXECUTED表

BINLOG中的GTID? EVENT

那么既然有了BINLOG的GTID EVENT進行持久化那么為什么還需要GTID_EXECUTED表呢？這實際上就是5.7.5過后的一個優化，我們可以反過來思考在5.6中如果使用了GTID 做從庫，從庫如果不開啟BINLOG并且同時設置LOG_SLAVE_UPDATES=TURE那么從庫的執行過的GTID事務是沒有辦法持久化的。我們來一段5.6官方文檔對于搭建GTID從庫的其中一步：

Step3: Restart both serverswithGTIDs enabled. To enable binary loggingwithglobaltransaction identifiers, each server must be startedwithGTID mode, binary logging, slave updatelogging enabled, andwithstatements that are unsafeforGTID-based replication disabled. In addition,you should prevent unwanted or accidental updatesfrombeing performed on either server by startingbothinread-only mode. This means that both servers must be startedwith(at least) the options showninthe following invocationofmysqld_safe:shell> mysqld_safe --gtid_mode=ON --log-bin --log-slave-updates --enforce-gtid-consistency &

開啟BINLOG同時設置設置LOG_SLAVE_UPDATES=TURE必然造成一個問題，實際上從庫很多時候我們是不需要做級聯SLAVE，設置LOG_SLAVE_UPDATES=TURE會造成需要額外的空間和性能開銷。自然這種情況下我們需要另外的一種GTID持久化介質，而并不是BINLOG中的GTID EVENT。為了解決這個問題，5.7中GTID_EXECUTED表應運而生了。然而GTID_EXECUTED表是否需要實時更新呢？顯然在slave端不開啟BINLOG或者開啟BINLOG不設置LOG_SLAVE_UPDATES=TURE的情況下它需要實時更新，因為I/OTHREAD執行過得GTID是必須持久化的，而在主庫上因為有BINLOG的GTID EVENT的存在他是不需要實時更新的，這樣不同的對待方式也能夠減輕負擔提高性能。

總結

以上是生活随笔為你收集整理的mysql gtid深入_深入理解MySQL 5.7 GTID系列（四）:mysql.gtid_executedPREVIOUS GTID EVENT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。