Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


13.4.1.1 PURGE BINARY LOGS 構文

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

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

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

このステートメントは、サーバーがバイナリロギングを有効にする --log-bin オプションで起動されていない場合は何の効果もありません。

例:

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

BEFORE バリアントの datetime_expr 引数は、DATETIME 値 ('YYYY-MM-DD hh:mm:ss' 形式の値) に評価されます。

このステートメントは、スレーブがレプリケートしている間も安全に実行できます。それらを停止する必要はありません。削除しようとしているログファイルのいずれかを現在読み取っているアクティブなスレーブが存在する場合、このステートメントは何もしません。MySQL 5.6.12 以降では、このような場合はエラーで失敗します。(Bug #13727933) ただし、スレーブが接続されていないときに、そのスレーブがまだ読み取っていないログファイルのいずれかを偶然にパージした場合、そのスレーブは再接続したあとにレプリケートできなくなります。

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

  1. 各スレーブサーバー上で、SHOW SLAVE STATUS を使用して、そのスレーブサーバーがどのログファイルを読み取っているかをチェックします。

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

  3. すべてのスレーブ間でもっとも早いログファイルを特定します。これがターゲットファイルです。すべてのスレーブが最新である場合は、そのリスト上の最後のログファイルになります。

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

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

また、特定の日数が経過したらバイナリログファイルが自動的に期限切れになるように、expire_logs_days システム変数を設定することもできます (セクション5.1.4「サーバーシステム変数」を参照してください)。レプリケーションを使用している場合、スレーブがマスターよりも遅延できる最大日数を下回らないような変数を設定するようにしてください。

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