binlog_gtid_simple_recovery

此變數控制在 MySQL 啟動或重新啟動時，搜尋 GTID 期間如何迭代二進制日誌檔案。

當 binlog_gtid_simple_recovery=TRUE (預設值) 時，gtid_executed 和 gtid_purged 的值會在啟動時根據最近和最舊二進位日誌檔案中的 Previous_gtids_log_event 值計算得出。有關計算的說明，請參閱「gtid_purged 系統變數」。此設定在伺服器重新啟動期間僅存取兩個二進位日誌檔案。如果伺服器上的所有二進位日誌都是使用 MySQL 5.7.8 或更高版本產生的，則始終可以安全地使用 binlog_gtid_simple_recovery=TRUE。

如果伺服器上存在來自 MySQL 5.7.7 或更早版本的任何二進位日誌 (例如，在將較舊伺服器升級到 MySQL 8.4 之後)，且設定 binlog_gtid_simple_recovery=TRUE，則在以下兩種情況下，gtid_executed 和 gtid_purged 可能會初始化不正確：

如果在任何一種情況下計算出的 GTID 集不正確，即使伺服器稍後以 binlog_gtid_simple_recovery=FALSE 重新啟動，它仍然不正確。如果這些情況中的任何一種適用或可能適用於伺服器，請在啟動或重新啟動伺服器之前設定 binlog_gtid_simple_recovery=FALSE。

當設定 binlog_gtid_simple_recovery=FALSE 時，如「gtid_purged 系統變數」中所述的 gtid_executed 和 gtid_purged 計算方法會更改為依序讀取二進位日誌檔案，如下所示：

enforce_gtid_consistency

根據此變數的值，伺服器會強制執行 GTID 一致性，僅允許執行可以使用 GTID 安全記錄的語句。您必須在啟用基於 GTID 的複製之前，將此變數設定為 ON。

enforce_gtid_consistency 可以配置的值為：

僅當語句發生二進位日誌記錄時，--enforce-gtid-consistency 才會生效。如果伺服器上禁用了二進位日誌記錄，或者如果語句因為被篩選器刪除而未寫入二進位日誌，則不會檢查或強制執行未記錄語句的 GTID 一致性。

當 enforce_gtid_consistency 設定為 ON 時，只能記錄可以使用 GTID 安全語句記錄的語句，因此此處列出的操作不能與此選項一起使用：

有關更多資訊，請參閱「第 19.1.3.7 節，使用 GTID 進行複製的限制」。

在 MySQL 5.7 之前以及該版本系列的早期版本中，布林值 enforce_gtid_consistency 的預設值為 OFF。為了保持與這些早期版本的相容性，枚舉的預設值為 OFF，並且不帶值的設定 --enforce-gtid-consistency 會被解釋為將值設定為 ON。該變數還具有多個用於值的文字別名：0=OFF=FALSE、1=ON=TRUE、2=WARN。這與其他枚舉類型不同，但保持與先前版本中使用的布林型別的相容性。這些變更會影響變數的傳回值。SELECT @@ENFORCE_GTID_CONSISTENCY、SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY' 和 SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY' 都會傳回文字形式，而不是數字形式。這是一個不相容的變更，因為 @@ENFORCE_GTID_CONSISTENCY 會傳回布林值的數字形式，但會為 SHOW 和 Information Schema 傳回文字形式。

gtid_executed

與全域範圍一起使用時，此變數包含伺服器上執行的所有交易的集合表示形式，以及 SET gtid_purged 語句設定的 GTID。這與 SHOW BINARY LOG STATUS 和 SHOW REPLICA STATUS 輸出中 Executed_Gtid_Set 資料行的值相同。此變數的值是一個 GTID 集，有關更多資訊，請參閱「GTID 集」。

伺服器啟動時，會初始化 @@GLOBAL.gtid_executed。有關如何依序讀取二進位日誌以填入 gtid_executed 的更多資訊，請參閱 binlog_gtid_simple_recovery。然後，在執行交易時，或在執行任何 SET gtid_purged 語句時，會將 GTID 新增到集合中。

可以在任何給定時間在二進位日誌中找到的交易集合等於 GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged)；也就是說，二進位日誌中所有尚未清除的交易。

發出 RESET BINARY LOGS AND GTIDS 會導致此變數重設為空字串。GTID 不會以其他方式從此集合中移除，除非由於 RESET BINARY LOGS AND GTIDS 而清除集合。

gtid_executed_compression_period

每次處理這麼多交易時，壓縮 mysql.gtid_executed 表。當伺服器上啟用二進位日誌記錄時，不會使用此壓縮方法，而是每次二進位日誌輪換時都會壓縮 mysql.gtid_executed 表。當伺服器上禁用二進位日誌記錄時，壓縮執行緒會休眠，直到執行指定數量的交易，然後喚醒以執行 mysql.gtid_executed 表的壓縮。將此系統變數的值設定為 0 表示執行緒永遠不會喚醒，因此不會使用此明確的壓縮方法。相反，會根據需要隱式地進行壓縮。

InnoDB 交易由單獨的程序寫入 mysql.gtid_executed 表，非 InnoDB 交易也是如此。如果伺服器混合使用 InnoDB 交易和非 InnoDB 交易，則由此系統變數控制的壓縮會干擾此程序的工作，並可能顯著降低其速度。因此，從該版本開始，建議您將 gtid_executed_compression_period 設定為 0。

所有交易（無論儲存引擎如何）都由相同的程序寫入 mysql.gtid_executed 表，並且 gtid_executed_compression_period 的預設值為 0。

有關更多資訊，請參閱「mysql.gtid_executed 表壓縮」。

gtid_mode

控制是否啟用基於 GTID 的記錄，以及日誌可以包含哪種類型的交易。您必須擁有足夠的權限來設定全域系統變數。請參閱第 7.1.9.1 節，「系統變數權限」。enforce_gtid_consistency 必須設定為 ON，您才能設定 gtid_mode=ON。在修改此變數之前，請參閱第 19.1.4 節，「在線上伺服器上變更 GTID 模式」。

記錄的交易可以是匿名的或使用 GTID。匿名交易依靠二進位日誌檔案和位置來識別特定交易。GTID 交易具有用於參考交易的唯一識別碼。不同的模式如下

從一個值變更為另一個值一次只能執行一個步驟。例如，如果 gtid_mode 目前設定為 OFF_PERMISSIVE，則可以變更為 OFF 或 ON_PERMISSIVE，但不能變更為 ON。

gtid_purged 和 gtid_executed 的值是持久的，無論 gtid_mode 的值為何。因此，即使變更 gtid_mode 的值之後，這些變數仍會包含正確的值。

gtid_next

此變數用於指定是否以及如何取得下一個 GTID（請參閱第 19.1.3 節，「使用全域交易識別碼進行複製」）。

設定此系統變數的工作階段值是受限的操作。工作階段使用者必須擁有 REPLICATION_APPLIER 權限（請參閱第 19.3.3 節，「複製權限檢查」），或足以設定受限工作階段變數的權限（請參閱第 7.1.9.1 節，「系統變數權限」）。

gtid_next 可以採用下列任何值

剛才列出的選項中，哪些有效取決於 gtid_mode 的設定；如需詳細資訊，請參閱第 19.1.4.1 節，「複製模式概念」。如果 gtid_mode 為 OFF，則設定此變數無效。

將此變數設定為 UUID:NUMBER 或 UUID:TAG:NUMBER，並提交或回溯交易後，必須再次發出明確的 SET gtid_next 陳述式，才能執行任何其他陳述式。

當對非暫時性資料表與暫時性資料表，或使用交易式儲存引擎的暫時性資料表與使用非交易式儲存引擎的暫時性資料表組合使用時，DROP TABLE 或 DROP TEMPORARY TABLE 會失敗並出現明確的錯誤。

如需詳細資訊，請參閱gtid_next 系統變數，以及第 19.1.4 節，「在線上伺服器上變更 GTID 模式」。

gtid_owned

此唯讀變數主要供內部使用。其內容取決於其範圍。

gtid_purged

gtid_purged 系統變數的全域值 (@@GLOBAL.gtid_purged) 是一個 GTID 集合，包含伺服器上已提交，但伺服器上任何二進位日誌檔案中都不存在的全部交易的 GTID。gtid_purged 是 gtid_executed 的子集。gtid_purged 中包含以下類別的 GTID

伺服器啟動時，gtid_purged 的全域值會初始化為 GTID 集合。如需此 GTID 集合計算方式的相關資訊，請參閱gtid_purged 系統變數。如果伺服器上存在 MySQL 5.7.7 或更舊版本的二進位日誌，您可能需要在伺服器的組態檔案中設定 binlog_gtid_simple_recovery=FALSE，以產生正確的計算結果。如需需要此設定的情況詳細資訊，請參閱 binlog_gtid_simple_recovery 的描述。

您必須擁有 TRANSACTION_GTID_TAG 才能設定 gtid_purged。

發出 RESET BINARY LOGS AND GTIDS 會導致 gtid_purged 的值重設為空字串。

您可以設定 gtid_purged 的值，以便在伺服器上記錄已套用特定 GTID 集合中的交易，即使它們不存在於伺服器上的任何二進位日誌中。此動作的一個範例用途是當您在伺服器上還原一或多個資料庫的備份，但您沒有伺服器上包含交易的相關二進位日誌時。

有兩種方式可以設定 gtid_purged 的值。你可以將 gtid_purged 的值替換為你指定的 GTID 集合，或者你可以將你指定的 GTID 集合附加到 gtid_purged 已持有的 GTID 集合中。如果伺服器沒有現有的 GTID，例如一個空伺服器，你要用現有資料庫的備份來佈建它，那麼這兩種方法的效果相同。如果你要還原的備份與伺服器上已有的交易重疊，例如用使用 mysqldump 從來源資料庫製作的部分傾印來替換損壞的表格（其中包含伺服器上所有交易的 GTID，即使傾印是部分的），請使用第一種方法，即替換 gtid_purged 的值。如果你要還原的備份與伺服器上已有的交易不相關，例如使用來自兩個不同伺服器的傾印來佈建多來源複本，請使用第二種方法，即將值新增到 gtid_purged 中。