此指令取代舊的 RESET MASTER
指令,該指令不再支援。
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
的效果在兩個關鍵方面有所不同
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
以清除任何與之相關聯的二進制日誌項目和識別符。
在驗證設定、重置來源和複本,並確保來源或複本上沒有由測試產生的不必要資料或二進制日誌檔案後,您可以啟動複本並開始複製。