mysql> SELECT * FROM mysql.gtid_executed;

mysql.gtid_executed表是由MySQL服務器提供給內部使用的。它允許副本在副本上禁用二進制日志記錄時使用GTIDs，并允許在二進制日志丟失時保留GTID狀態。RESET MASTER命令，gtid_executed表將被清除。

服務意外停止的情況下，當前二進制日志文件中的gtid集不會保存在gtid_executed表。在恢復期間，這些gtid將從二進制日志文件添加到表中，以便可以繼續復制。

3. gtid_executed

若MySQL服務器啟用了二進制日志，則表mysql.gtid_executed的更新僅在二進制rotation時發生，因為發生重啟等情況依舊可以通過掃描二進制日志判斷得知當前運行的GTID位置。

簡單來說，該表會記錄當前執行的GTID

在MySQL 5.6中必須配置參數log_slave_updates的最重要原因在于當slave重啟后，無法得知當前slave已經運行到的GTID位置，因為變量gtid_executed是一個內存值：

MySQL 5.7將gtid_executed這個值給持久化。采用的技巧與MySQL 5.6處理SQL thread保存位置的方式一樣，即將GTID值持久化保存在一張InnoDB表中，并與用戶事務一起進行提交，從而實現數據的一致性。

觸發條件：

在binlog發生rotate(flush binary logs/達到max_binlog_size)或者關閉服務時，會把所有寫入到binlog中的Gtid信息寫入到mysql.gtid_executed表。

從庫：如果沒有開啟log_bin或者沒有開啟log_slave_updates，從庫在應用relay-log中的每個事務會執行一個insert mysql.gtid_executed操作。

常用命令

1. gtid設置

gtid_mode=ON #必選

enforce-gtid-consistency=true #必選

log-bin=mysql #5.6必選 5.7.5和它之后可選，為了高可用，最好設置

server-id=1 #開啟log-bin的必須設置

log-slave-updates=ON # 5.6必選 5.7.5和它之后可選，為了高可用切換，最好設置ON

2. gtid跳過 gtid_next

stop slave;

set gtid_next='d74faa2d-5819-11e8-b248-ac853db70398:10603';

begin;commit;

set gtid_next='automatic';

start slave;

備注;該操作類似于sql_slave_skip_counter，只是跳過錯誤，不能保證數據一致性，需要人工介入，固強烈建議從機開啟read_only=1

3. gtid清除gtid_pureged

命令的實際意義：因沒有binlog信息(expire_logs_days)，不考慮這些gtid確認和回滾。常用備份恢復，搭建從庫的時候使用。

自動觸發機制：flush，服務器重新啟動

使用場景：

在副本上禁用二進制日志記錄提交的復制事務的GTIDs。

寫入二進制日志文件的事務的GTIDs，該文件現在已被清除。

通過語句set @@GLOBAL.gtid_purged顯式添加到集合中的gtid。

mysqldump --set-gtid-purged=off/on 參數;

是否將GTID_PURGED’添加到輸出中

4. gtid升級

pos升級gtid方式，條件允許建議重新搭建從庫的方式。以下方式存在風險。

gtid_mode可選值

ON：完全打開GTID，如果打開狀態的備庫接受到不帶GTID的事務，則復制中斷

ON_PERMISSIV：可以認為是打開gtid前的過渡階段，主庫在設置成該值后會產生GTID，同時備庫依然容忍帶GTID和不帶GTID的事務

OFF_PERMISSIVE：可以認為是關閉GTID前的過渡階段，主庫在設置成該值后不再生成GTID,備庫在接受到帶GTID和不帶GTID事務都可以容忍。主庫在關閉GTID時，執行事務會產生一個Anonymous_Gtid事件，會在備庫執行：set @@session.gtid_next=‘anonymous’

OFF：徹底關閉GTID，如果關閉狀態的備庫收到帶GTID的事務，則復制中斷

從position模式切換到GTID模式：

1)在每個sever執行WARN模式:

這一步設置之后，使得所有事物都允許違反GTID的一致性

mysql>SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;

#這是第一個重要步驟. 您必須確保在進入下一步驟之前不會在錯誤日志中生成警告.

2)在每個sever執行ON模式:

以確保所有的事務都不能違反GTID一致性

mysql>SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;

3)在每個sever執行OFF模式:

這一步表示，新的事務是匿名的，同事允許復制的事務是GTID或是匿名的

mysql>SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

#需要確保這一步操作在所有的服務器上執行

4)在每個sever執行ON模式:

這一步表示，新的事務是GTID的，同事允許復制的事務是GTID或是匿名的

mysql>SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

#需要確保這一步操作在所有的服務器上執行

5)在每個服務器上,等待狀態變量ONGOING_ANONYMOUS_TRANSACTION_COUNT為零. 可以使用如下方式查詢:

mysql>SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';

#在所有從庫上查詢該狀態，必須為0 才能進行下一步。該狀態寶石已標示為匿名的正在#進行的事務數量，如果狀態值為0表示無事務等待被處理

等待生成到步驟5的所有事務復制到所有服務器. 可以在不停止更新的情況下執行此操作：唯一重要的是所有anonymous transactions都被復制了.

6)GTID_MODE = ON在每所有服務器上執行:

mysql>SET @@GLOBAL.GTID_MODE = ON;

7)修改每個my.cnf文件:

gtid-mode=ON

ENFORCE_GTID_CONSISTENCY = ON

8)上面復制雖然配置了GTID模式，但還是基于Binlog方式的。可通過選項MASTER_AUTO_POSITION設置為1，把復制調整為基于GTID模式的復制，具體操作如下:

mysql>STOP SLAVE [FOR CHANNEL 'channel'];

mysql>CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel'];

mysql>START SLAVE [FOR CHANNEL 'channel'];

5. gtid 壓縮 gtid_executed_compression_period

啟用GTID時，服務器會定期在mysql.gtid_executed表上執行此類壓縮。通過設置gtid_executed_compression_period系統變量，可以控制壓縮表之前允許的事務數，從而控制壓縮率。該變量的默認值為1000; 這意味著，默認情況下，在每1000次事務之后執行表壓縮。

將gtid_executed_compression_period設置為0可以防止執行壓縮; 但是，如果執行此操作，應該為gtid_executed表可能需要的磁盤空間量的大幅增加做好準備。

使用以下語句查詢：

mysql> select thread_id,thread_os_id,name, processlist_command,processlist_statefrom `performance_schema`.threads where name like '%compress%';+-----------+--------------+--------------------------------+---------------------+-------------------+| thread_id |thread_os_id | name |processlist_command | processlist_state |+-----------+--------------+--------------------------------+---------------------+-------------------+| 26 |8024| thread/sql/compress_gtid_table |Daemon | Suspending |+-----------+--------------+--------------------------------+---------------------+-------------------+

備注：如發現 processlist_state 值一直是: "Compressing gtid_executed table"說明進行壓縮。記錄鎖的內存從操作系統申請，所以當表gtid_executed不斷增大時，最終會導致MySQL OOM。

6. binlog_gtid_simple_recovery

MySQL啟動或重啟時在搜索GTIDs期間迭代二進制日志文件的方式。就是為了初始化 gtid_executed ， gtid_purged參數，掃描binlog 或則 event相關信息

MySQL 5.7.7或更老版本的二進制日志，需要在設置binlog_gtid_simple_recovery=FALSE，如果存在非gtid的binlog比較多的時候，會非常影響性能的。

限制

到目前為止已經發展完善，但存在一些場景是受限的。

1. create table xxx as select：

拆分成兩部分：

create table xxxx like table;

insert into xxxx select *from table;

2. 臨時表的限制

使用GTID復制模式：

1.不支持create temporary table 和 drop temporary table。

2.在autocommit=1的情況下可以創建臨時表，

3.Master端創建臨時表不產生GTID信息，所以不會同步到slave，但是在刪除臨時表的時候會產生GTID會導致，主從中斷.

3.事務操作

涉及非事務性存儲引擎的更新，非事務性存儲引擎事務性存儲引擎更新表則不能在同一條語句或同一事務中執行。

4.mysql_upgrade

GTID模式和mysql_upgrade。在啟用全局事務標識符(GTIDs)的情況下運行時，不要通過mysql_upgrade(——write binlog選項)啟用二進制日志記錄。

5.sql_slave_skip_counter

傳統模式的跳過postion方式gtid模式下不支持。

總結

1. gtid能不能做的更好。返回搜狐，查看更多

像并行復制的writeset一樣 壓縮機制

binlog內容能不能更簡潔

gtid能不能實現物理級別的復制模式

總結

以上是生活随笔為你收集整理的如何查看mysql的gtid_汇总丨MySQL GTID技术点，看这一篇就够了！的全部內容，希望文章能夠幫你解決所遇到的問題。

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