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 9.0 之後），使用 binlog_gtid_simple_recovery=TRUE 時，gtid_executed 和 gtid_purged 可能在以下兩種情況下初始化不正確：

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

當設定 binlog_gtid_simple_recovery=FALSE 時，計算 gtid_executed 和 gtid_purged 的方法（如「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 和資訊綱要的文字形式。

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 的值。