このページは機械翻訳したものです。

13.4.1.1 PURGE BINARY LOGS ステートメント

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

バイナリログは、MySQL サーバーによって行われたデータ変更に関する情報を含む一連のファイルです。 このログは一連のバイナリログファイルのほか、インデックスファイルで構成されています (セクション5.4.4「バイナリログ」を参照してください)。

PURGE BINARY LOGS ステートメントは、指定されたログファイル名または日付の前にあるログインデックスファイルにリストされているすべてのバイナリログファイルを削除します。 BINARY と MASTER はシノニムです。 削除されたログファイルはインデックスファイル内に記録されているリストからも削除されるため、特定のログファイルがそのリスト内の先頭になります。

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'形式の値) に評価される必要があります。

このステートメントは、レプリカのレプリケート中に安全に実行できます。 それらを停止する必要はありません。 現在削除しようとしているログファイルのいずれかを読み取っているアクティブレプリカがある場合、このステートメントでは、使用中のログファイルまたはそのログファイルより後のログファイルは削除されませんが、以前のログファイルは削除されます。 この状況では、警告メッセージが発行されます。 ただし、レプリカが接続されておらず、まだ読み取られていないログファイルのいずれかをパージする場合、レプリカは再接続後にレプリケートできません。

バイナリログファイルを安全にパージするには、次の手順に従います。

1. 各レプリカで、SHOW REPLICA | SLAVE STATUS を使用して読み取るログファイルを確認します。

2. SHOW BINARY LOGS を使用して、ソースのバイナリログファイルのリストを取得します。

3. すべてのレプリカの中で最も古いログファイルを確認します。 これがターゲットファイルです。 すべてのレプリカが最新の場合、これはリストの最後のログファイルです。

4. 削除しようとしているすべてのログファイルのバックアップを作成します。 (この手順はオプションですが、常に実行することをお勧めします。)

5. ターゲットファイルの直前までのすべてのログファイルをパージします。

PURGE BINARY LOGS TO と PURGE BINARY LOGS BEFORE はどちらも、.index ファイルにリストされているバイナリログファイルが、ほかの何らかの手段 (Linux 上での rm の使用など) によってシステムから削除されている場合はエラーで失敗します。 (Bug #18199、Bug #18453) このようなエラーに対処するには、.index ファイル (これは単純なテキストファイルです) を手動で編集して、実際に存在するバイナリログファイルのみがリストされていることを確認したあと、失敗した PURGE BINARY LOGS ステートメントを再度実行します。

バイナリログファイルは、サーバーのバイナリログの有効期限後に自動的に削除されます。 ファイルの削除は、起動時およびバイナリログのフラッシュ時に実行できます。 デフォルトのバイナリログの有効期限は 30 日です。 binlog_expire_logs_seconds システム変数を使用して、別の有効期限を指定できます。 レプリケーションを使用している場合は、レプリカがソースより遅れる可能性のある最大時間以下の有効期限を指定する必要があります。