MySQL 9.0 版本注意事項
RESET BINARY LOGS AND GTIDS [TO binary_log_file_index_number]警告
請謹慎使用此語句，以確保您不會遺失任何想要的二進位日誌檔案資料和 GTID 執行歷史記錄。
RESET BINARY LOGS AND GTIDS 需要 RELOAD 權限。
對於啟用二進位日誌記錄的伺服器 (log_bin 為 ON)，RESET BINARY LOGS AND GTIDS 會刪除所有現有的二進位日誌檔案，並重設二進位日誌索引檔案，將伺服器重設為啟動二進位日誌記錄之前的狀態。會建立新的空白二進位日誌檔案，以便可以重新啟動二進位日誌記錄。
對於使用 GTID 的伺服器（gtid_mode 為 ON），發出 RESET BINARY LOGS AND GTIDS 會重設 GTID 執行歷史記錄。gtid_purged 系統變數的值會設定為空字串（''），gtid_executed 系統變數的全域值（但不是工作階段值）會設定為空字串，並且會清除 mysql.gtid_executed 資料表（請參閱mysql.gtid_executed 資料表）。如果啟用 GTID 的伺服器已啟用二進位日誌記錄，RESET BINARY LOGS AND GTIDS 也會如上所述重設二進位日誌。請注意，即使啟用 GTID 的伺服器是停用二進位日誌記錄的副本，RESET BINARY LOGS AND GTIDS 也是重設 GTID 執行歷史記錄的方法；RESET REPLICA 對 GTID 執行歷史記錄沒有任何影響。如需重設 GTID 執行歷史記錄的詳細資訊，請參閱重設 GTID 執行歷史記錄。
發出不含選用 TO 子句的 RESET BINARY LOGS AND GTIDS 會刪除索引檔案中列出的所有二進位日誌檔案，將二進位日誌索引檔案重設為空白，並建立從 1 開始的新二進位日誌檔案。在重設之後，使用選用的 TO 子句，從 1 以外的數字開始二進位日誌檔案索引。
請檢查您使用的索引號碼值是否合理。如果您輸入的值不正確，您可以透過發出另一個有或沒有 TO 子句的 RESET BINARY LOGS AND GTIDS 陳述式來更正此問題。如果您不更正超出範圍的值，則伺服器將無法重新啟動。
以下範例示範 TO 子句的用法
RESET BINARY LOGS AND GTIDS TO 1234;
SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 | 154 | No |
+-------------------+-----------+-----------+重要
不含 TO 子句的 RESET BINARY LOGS AND GTIDS 的效果與 PURGE BINARY LOGS 的效果在以下 2 個主要方面不同
RESET BINARY LOGS AND GTIDS會移除索引檔案中列出的所有二進位日誌檔案，只留下一個數字後綴為.000001的空白二進位日誌檔案，而編號不會被PURGE BINARY LOGS重設。RESET BINARY LOGS AND GTIDS不適用於在任何副本正在執行時使用。RESET BINARY LOGS AND GTIDS在副本正在執行時使用時的行為是未定義的（因此不受支援），而PURGE BINARY LOGS可以在副本正在執行時安全地使用。
當您第一次設定來源和副本時，不含 TO 子句的 RESET BINARY LOGS AND GTIDS 證明很有用，如此您可以如下所述驗證設定
啟動來源和副本，並啟動複寫（請參閱第 19.1.2 節「設定基於二進位日誌檔案位置的複寫」）。
在來源上執行幾個測試查詢。
檢查查詢是否已複寫到副本。
當複寫正確執行時，發出
STOP REPLICA，然後發出RESET REPLICA（兩者都在副本上），然後確認副本上沒有測試查詢的不必要資料。接著，發出RESET BINARY LOGS AND GTIDS（也在副本上）以移除二進位日誌和相關的交易 ID。從來源中移除不必要的資料，然後發出
RESET BINARY LOGS AND GTIDS以清除與其關聯的任何二進位日誌項目和識別碼。
在驗證設定、重設來源和副本並確保測試產生之不必要的資料或二進位日誌檔案未留在來源或副本上之後，您可以啟動副本並開始複寫。