MySQL :: MySQL 8.4 參考手冊 :: 15.4.1.1 PURGE BINARY LOGS 語法

版本 8.4

8.0 日文

MySQL 8.4 參考手冊 / ... / PURGE BINARY LOGS 陳述式

15.4.1.1 PURGE BINARY LOGS 陳述式

PURGE BINARY LOGS {
    TO 'log_name'
  | BEFORE datetime_expr
}

二進制日誌是一組檔案，其中包含 MySQL 伺服器所做資料修改的相關資訊。該日誌由一組二進制日誌檔加上一個索引檔組成（請參閱第 7.4.4 節「二進制日誌」）。

PURGE BINARY LOGS 陳述式會刪除日誌索引檔中所列、指定日誌檔名或日期之前的所有二進制日誌檔。刪除的日誌檔也會從索引檔中記錄的清單中移除，因此給定的日誌檔會變成清單中的第一個。

PURGE BINARY LOGS 需要 BINLOG_ADMIN 權限。如果伺服器啟動時未使用 --log-bin 選項來啟用二進制日誌，則此陳述式無效。

範例

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

BEFORE 變體的 datetime_expr 引數應評估為 DATETIME 值（'YYYY-MM-DD hh:mm:ss' 格式的值）。

PURGE BINARY LOGS 在複本正在複製時執行是安全的。您不需要停止它們。如果您有一個目前正在讀取您嘗試刪除的日誌檔的活動複本，則此陳述式不會刪除正在使用的日誌檔或晚於該日誌檔的任何日誌檔，但會刪除任何較早的日誌檔。在這種情況下，會發出警告訊息。但是，如果複本未連線，而您剛好清除它尚未讀取的其中一個日誌檔，則複本在重新連線後無法複製。

PURGE BINARY LOGS 在執行個體的 LOCK INSTANCE FOR BACKUP 陳述式生效時，無法發出，因為它會透過從伺服器中移除檔案來違反備份鎖定的規則。

若要安全地清除二進制日誌檔，請遵循以下步驟

在每個複本上，使用 SHOW REPLICA STATUS 來檢查它正在讀取哪個日誌檔。
使用 SHOW BINARY LOGS 取得來源上二進制日誌檔的清單。
判斷所有複本中最舊的日誌檔。這是目標檔案。如果所有複本都是最新的，則這是清單上的最後一個日誌檔。
備份您即將刪除的所有日誌檔。（此步驟是選用的，但始終建議執行。）
清除所有直到但不包含目標檔案的日誌檔。

當 .index 檔案中列出的二進制日誌檔已透過其他方式（例如在 Linux 上使用 rm）從系統中移除時，PURGE BINARY LOGS TO 和 PURGE BINARY LOGS BEFORE 都會因錯誤而失敗。（錯誤 #18199，錯誤 #18453）若要處理這類錯誤，請手動編輯 .index 檔案（這是一個簡單的文字檔），以確保它只列出實際存在的二進制日誌檔，然後再次執行失敗的 PURGE BINARY LOGS 陳述式。

二進制日誌檔會在伺服器的二進制日誌過期時間過後自動移除。檔案的移除可能發生在啟動時和二進制日誌刷新時。預設的二進制日誌過期時間為 30 天。您可以使用 binlog_expire_logs_seconds 系統變數指定替代的過期時間。如果您使用複製，您應指定的過期時間不得低於複本可能落後於來源的最大時間量。