MySQL GTID生命週期

根據MySQL官方文件， GTID生命週期如下：

  1. 當一個事務在源端執行並提交後，此事務就被賦予一個由源資料庫的UUID與最小的未被使用的事務序列號。GTID被寫入源端的binlog。如果一個事務沒有被寫入binlog(原文：for example, because the transaction was filtered out, or the transaction was read-only), 那麼它就不會被賦予GTID

 2. 如果一個GTID被指派給一個事務，那麼它就被作為一個原子性的操作在事務開始時就被寫入了binglog（作為GTID_LOG_EVENT）。只要binlog被迴圈使用或者服務關閉，資料庫服務會將所有的在之前的binlog中被寫入的GTID寫入到mysql.gtid_executed

3.  當GTID被賦予給一個事務後，它就很快被加入到系統引數gtid_executed, 以非原子寫的方式（@@GLOBAL.gtid_executed）。GTID集合包含了一系列已經被提交的事務代表，它們被用於代表複製時服務端的狀態。表mysql.gtid_executed並不包含完整的GTID集合，系統引數gtid_executed才是完整的。因為最新的事務，其實都是在binlog中。

  原文: 

If a GTID was assigned for the transaction, the GTID is externalized non-atomically (very shortly

after the transaction is committed) by adding it to the set of GTIDs in the gtid_executed

system variable (@@GLOBAL.gtid_executed). This GTID set contains a representation of the

set of all committed GTID transactions, and it is used in replication as a token that represents

the server state. With binary logging enabled (as required for the source), the set of GTIDs in

the gtid_executed system variable is a complete record of the transactions applied, but the

mysql.gtid_executed table is not, because the most recent history is still in the current binary

log file.

4. 當binlog被傳輸到複製端之後，它被儲存在複製端的relay log當中。複製端讀取GTID，並設定系統引數gtid_next, 告訴複製端下一個事務必須使用這個GTID進行記錄。請記住這一點：GTID_NEXT引數是session級別生效的

5.  複製端必須在處理事務之前，必須驗證這個事務沒有被其他執行緒持有。複製端必須保證只有此GTID的事務沒有被應用，也必須保證持有這個GTID的事務沒有被其他執行緒所讀取但還沒有進行提交。如果多個複製執行緒嘗試同時去應用相同GTID的事務，服務端只允許一個執行緒執行。gtid_owned系統參數列示哪個執行緒持有了哪個GTID。如果一個GTID已經被使用，沒有錯誤丟擲，此事務會被自動跳過。

   原文： 

The replica verifies that no thread has yet taken ownership of the GTID in gtid_next in order to

process the transaction. By reading and checking the replicated transaction's GTID first, before

processing the transaction itself, the replica guarantees not only that no previous transaction having

this GTID has been applied on the replica, but also that no other session has already read this

GTID but has not yet committed the associated transaction. So if multiple clients attempt to apply

the same transaction concurrently, the server resolves this by letting only one of them execute. The

gtid_owned system variable (@@GLOBAL.gtid_owned) for the replica shows each GTID that is

currently in use and the ID of the thread that owns it. If the GTID has already been used, no error is

raised, and the auto-skip function is used to ignore the transaction.

6. 如果GTID還未被使用，複製端將此GTID應用到已經被複制的事務之上。因系統引數gtid_next是被設定為源端已經被指定的GTID, 複製端不會嘗試去產生一個新的GTID，轉而使用gtid_next引數中的GTID

原文：

If the GTID has not been used, the replica applies the replicated transaction. Because gtid_next

is set to the GTID already assigned by the source, the replica does not attempt to generate a new

GTID for this transaction, but instead uses the GTID stored in gtid_next.

7. 如果binlog在複製端被開啟，GTID在事務開始時被以原子寫的方式持久化，寫入到binlog當中（gtid_log_event）。當 binlog被迴圈使用或者服務被關閉時，被寫入到之前binlog的GTID都會被寫入到表mysql.gtid_executed

8. 若複製端未開啟binlog, GTID也在事務開始時被以原子寫入的方式持久化，直接寫入表mysql.gtid_executed中。MySQL會追加一個語句，當gtid被寫入到mysql.gtid_executed時。從8.0版本開始，無論是DDL還是DML操作都是原子性的。此種情況下，mysql.gtid_executed就是一個完整的已經在複製端被應用的GTID集合。

9. 事務在複製端被提交之後，很短時間內，這個GTID就會被加入到系統引數gtid_executed集合中。注意這個操作並不是原子性的。gtid_executed在源端代表了所有的已經提交的事務。如果目標端禁用了binlog， 那麼mysql.gtid_executed表就是一個完整的已經被提交的事務集合。 如果複製端開啟了binlog， 那麼一些GTID只會被寫入到binlog, 這就意味著，系統引數gtid_executed才是一個完整的記錄。

原文：

Very shortly after the replicated transaction is committed on the replica, the GTID is externalized

non-atomically by adding it to the set of GTIDs in the gtid_executed system variable

(@@GLOBAL.gtid_executed) for the replica. As for the source, this GTID set contains a

representation of the set of all committed GTID transactions. If binary logging is disabled on the

replica, the mysql.gtid_executed table is also a complete record of the transactions applied on

the replica. If binary logging is enabled on the replica, meaning that some GTIDs are only recorded

in the binary log, the set of GTIDs in the gtid_executed system variable is the only complete

record.