MySQL 5.6 リファレンスマニュアル  /  ...  /  mysqlbinlog — バイナリログファイルを処理するためのユーティリティー

4.6.8 mysqlbinlog — バイナリログファイルを処理するためのユーティリティー

サーバーのバイナリログは、データベースの内容に対する変更を記述するイベントを含むファイルで構成されます。サーバーはこれらのファイルをバイナリ形式で書き出します。内容をテキスト形式で表示するには、mysqlbinlog ユーティリティーを使用します。レプリケーションセットアップで、mysqlbinlog を使用して、スレーブサーバーが書き出したリレーログファイルの内容を表示することもできます。リレーログはバイナリログと同じ形式を持つからです。バイナリログおよびリレーログは、セクション5.2.4「バイナリログ」およびセクション17.2.2「レプリケーションリレーおよびステータスログ」でさらに説明します。

mysqlbinlog は次のように起動します。

shell> mysqlbinlog [options] log_file ...

たとえば binlog.000003 という名前のバイナリログファイルの内容を表示するには、このコマンドを使用してください。

shell> mysqlbinlog binlog.0000003

出力には、binlog.000003 に含まれるイベントが含まれます。ステートメントベースのロギングでは、イベント情報には SQL ステートメント、それが実行されたサーバーの ID、ステートメントが実行されたタイムスタンプ、かかった時間などが含まれます。行ベースのロギングでは、イベントは SQL ステートメントではなく行の変更を示します。ロギングモードの詳細はセクション17.1.2「レプリケーション形式」を参照してください。

イベントには、その前に追加情報を提供するヘッダーコメントがあります。例:

# at 141
#100309  9:28:36 server id 123  end_log_pos 245
  Query thread_id=3350  exec_time=11  error_code=0

最初の行で、at に続く数字はバイナリログファイル内でのイベントのファイルオフセット、つまり開始位置を示します。

2 行目は、イベントが発生したサーバー上でステートメントがいつ開始されたかを示す日付と時間で始まります。レプリケーションに関しては、このタイムスタンプがスレーブサーバーに伝播されます。server id はイベントが発生したサーバーの server_id 値です。end_log_pos は次のイベントが始まる場所 (すなわび、現在のイベントの終了位置 + 1) を示します。thread_id はイベントを実行したスレッドを示します。exec_time は、マスターサーバーではイベントの実行にかかった時間です。スレーブでは、これはスレーブでの実行終了時間からマスターでの実行開始時間を引いた差分です。この差は、レプリケーションがマスターからどの程度遅れているかを示します。error_code はイベントの実行結果を示します。ゼロはエラーが発生しなかったことを意味します。

注記

イベントグループを使用する場合は、イベントのファイルオフセットのグループ化およびイベントのコメントのグループ化ができます。これらのグループ化イベントをブランクファイルオフセットと間違えないでください。

mysqlbinlog からの出力は、(たとえばそれを mysql への入力として使用することによって) 再実行し、ログ内のステートメントをやり直せます。これはサーバーがクラッシュした際のリカバリ操作として便利です。ほかの使用例は、このセクションのあとの方の説明およびセクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください。

通常、mysqlbinlog を使用してバイナリログファイルを直接読み取り、ローカル MySQL サーバーに適用します。--read-from-remote-server オプションを使用してリモートサーバーからバイナリログを読み取ることも可能です。リモートバイナリログを読み取るために、接続パラメータオプションを指定してサーバーへの接続方法を示すことができます。これらのオプションは、--host--password--port--protocol, --socket、および --user です。--read-from-remote-server オプションも使用した場合以外は無視されます。

mysqlbinlog を大規模なバイナリログに対して実行する場合は、結果のファイルのためにファイルシステムに十分なスペースがあるように注意してください。mysqlbinlog が一時ファイル用に使用するディレクトリを構成するには、TMPDIR 環境変数を使用します。

mysqlbinlog は次のオプションをサポートします。これらはコマンド行またはオプションファイルの [mysqlbinlog] グループおよび [client] グループで指定できます。MySQL プログラムによって使用されるオプションファイルの詳細については、セクション4.2.6「オプションファイルの使用」を参照してください。

表 4.15 mysqlbinlog のオプション

形式 説明 導入
--base64-output バイナリログのエントリを base-64 エンコードで出力
--bind-address 指定されたネットワークインタフェースを使用して MySQL サーバーに接続 5.6.1
--binlog-row-event-max-size バイナリログの最大イベントサイズ
--character-sets-dir 文字セットがインストールされているディレクトリ
--connection-server-id テストとデバッグに使用。適用されるデフォルト値およびその他の事項については、テキストを参照してください。 5.6.20
--database このデータベースのみのエントリをリスト
--debug デバッグのログを書き込み
--debug-check プログラムの終了時にデバッグ情報を出力
--debug-info プログラムの終了時に、デバッグ情報、メモリー、および CPU の統計を出力
--default-auth 使用する認証プラグイン 5.6.2
--defaults-extra-file 通常のオプションファイルに加えてオプションファイルを読み取る
--defaults-file 指名されたオプションファイルのみを読み取る
--defaults-group-suffix オプショングループのサフィクス値
--disable-log-bin バイナリロギングを無効化
--exclude-gtids 提供された GTID セットのグループを表示しない 5.6.5
--force-if-open バイナリログファイルが開いているか適切にクローズしていない場合でも読み取る
--force-read mysqlbinlog が認識しないバイナリログイベントを読み取った場合、警告を出力
--help ヘルプメッセージを表示して終了
--hexdump コメント内にログの 16 進ダンプを表示
--host 指定されたホスト上で MySQL サーバーに接続
--idempotent サーバーが、このセッションからのバイナリログの更新を処理する間のみ、べき乗モードを使用
--include-gtids 提供された GTID セットのグループのみを表示 5.6.5
--local-load 指定されたディレクトリ内に LOAD DATA INFILE のローカル一時ファイルを準備
--login-path ログインパスオプションを .mylogin.cnf から読み取り 5.6.6
--no-defaults オプションファイルを読み取らない
--offset ログの最初の N エントリをスキップ
--password サーバーに接続する際に使用するパスワード
--plugin-dir プラグインがインストールされているディレクトリ 5.6.2
--port 接続に使用する TCP/IP ポート番号
--print-defaults デフォルトを出力
--protocol 使用する接続プロトコル
--raw イベントを生の (バイナリ) 形式で出力ファイルに書き込み
--read-from-remote-master バイナリログをローカルログファイルからではなく MySQL マスターから読み取り 5.6.5
--read-from-remote-server バイナリログをローカルログファイルからではなく MySQL サーバーから読み取り
--result-file 指定されたファイルに出力を送信
--secure-auth 古い (4.1.1 より前の) 形式でサーバーにパスワードを送信しない 5.6.17
--server-id 指定されたサーバー ID を持つサーバーによって作成されたイベントのみを抽出
--server-id-bits サーバー ID ビットが最大値未満に設定されている mysqld によってログが書き込まれた場合に、バイナリログのサーバー ID を解釈する方法を、mysqlbinlog に対して指定。MySQL Cluster バージョンの mysqlbinlog でのみサポート
--set-charset SET NAMES charset_name ステートメントを出力に追加
--shared-memory-base-name 共有メモリー接続に使用する共有メモリーの名前
--short-form ログに含まれるステートメントのみを表示
--skip-gtids GTID を出力しない。これは、GTID を含むバイナリログからのダンプファイルを書き込む場合に使用します。 5.6.5
--socket ローカルホストへの接続で、使用する Unix ソケットファイル
--ssl-crl 証明書失効リストを含むファイルのパス 5.6.3
--ssl-crlpath 証明書失効リストファイルを含むディレクトリのパス 5.6.3
--start-datetime タイムスタンプが datetime 引数と同じかそれよりあとの最初のイベントからバイナリログを読み取り
--start-position 位置が引数と同じかそれより大きい最初のイベントからバイナリログを読み取り
--stop-datetime タイムスタンプが datetime 引数と同じかそれより大きい最初のイベントでバイナリログの読み取りを停止
--stop-never 最後のバイナリログファイルの読み取り後、サーバーとの接続を維持
--stop-never-slave-server-id サーバーへの接続時にレポートするスレーブサーバー ID
--stop-position 位置が引数と同じかそれより大きい最初のイベントでバイナリログの読み取りを停止
--to-last-log MySQL サーバーから要求されたバイナリログの最後で停止せず、最後のバイナリログまで続けて出力
--user サーバーへの接続時に使用する MySQL ユーザー名
--verbose 行イベントを SQL ステートメントとして再構築
--verify-binlog-checksum バイナリログのチェックサムを検証 5.6.1
--version バージョン情報を表示して終了

  • --help, -?

    ヘルプメッセージを表示して終了します。

  • --base64-output=value

    このオプションは、イベントをいつ BINLOG ステートメントを使用して、base-64 文字列としてエンコードして表示するべきかを決定します。このオプションには次の可能な値があります (大文字小文字は区別されません)。

    • AUTO (「自動」) または UNSPEC (「未指定」) では、必要なときに (すなわち、形式記述イベントおよび行イベント) 自動的に BINLOG ステートメントを表示します。--base64-output オプションが指定されない場合は、効果は --base64-output=AUTO と同じです。

      注記

      自動的な BINLOG 表示は、mysqlbinlog の出力を使用してバイナリログファイルの内容を再実行する場合には、唯一の安全な動作です。その他のオプション値はデバッグまたはテスト専用です。これらのオプションで生成される出力には、すべてのイベントが実行可能な形式で含まれるわけではないからです。

    • NEVER を使用すると BINLOG ステートメントは表示されなくなります。mysqlbinlog は、BINLOG を使用して表示しなければならない行イベントが検出された場合にはエラーで終了します。

    • DECODE-ROWS は、--verbose オプションも指定することによって、行イベントをコメント付きの SQL ステートメントとしてデコードおよび表示することをユーザーが意図していることを、mysqlbinlog に指定します。NEVER と同様に、DECODE-ROWSBINLOG ステートメントの表示を抑制しますが、NEVER とは異なり、行イベントが検出されてもエラーで終了しません。

    --base64-output および --verbose の行イベント出力への影響を示す例は、セクション4.6.8.2「mysqlbinlog 行イベントの表示」を参照してください。

  • --bind-address=ip_address

    複数のネットワークインタフェースを持つコンピュータで、このオプションを使用して、MySQL サーバーへの接続に使用するインタフェースを選択します。

    このオプションは MySQL 5.6.1 からサポートされています。

  • --binlog-row-event-max-size=N

    コマンド行形式 --binlog-row-event-max-size=#
    許可されている値 (64 ビットプラットフォーム) 数値
    デフォルト 4294967040
    最小値 256
    最大値 18446744073709547520

    行ベースのバイナリログイベントの最大サイズをバイト単位で指定します。可能であれば、行はこのサイズより小さいイベントにグループ化されます。値は 256 の倍数であるべきです。デフォルトは 4G バイトです。

  • --character-sets-dir=path

    文字セットがインストールされているディレクトリ。セクション10.5「文字セットの構成」を参照してください。

  • --connection-server-id=server_id

    このオプションは、MySQL サーバーが BINLOG_DUMP_NON_BLOCK 接続フラグをサポートするかどうかをテストするために使用されます。このフラグは何らかの都合で MySQL 5.6.5 で削除され、MySQL 5.6.20 でリストアされました (Bug #18000079、Bug #71178)。通常の操作では不要です。

    このオプションの実質的なデフォルトと最小値は、mysqlbinlog がブロッキングモードで実行されているか非ブロッキングモードで実行されているかによって異なります。mysqlbinlog がブロッキングモードで実行されている場合は、デフォルト (および最小) 値は 1 です。非ブロッキングモードで実行されている場合は、デフォルト (および最小) 値は 0 です。

    このオプションは MySQL 5.6.20 で追加されました。

  • --database=db_name, -d db_name

    このオプションを使用すると、mysqlbinlog は、USE によって db_name がデフォルトデータベースとして選択されている間に発生するバイナリログ (ローカルログのみ) からのエントリを出力するようになります。

    mysqlbinlog--database オプションは、mysqld--binlog-do-db オプションと同様ですが、指定できるのは 1 つのデータベースのみです。--database を複数回指定すると、最後のインスタンスのみが使用されます。

    このオプションの影響は、ステートメントベースまたは行ベースのロギング形式のどちらが使用されているかによって異なります。これは、--binlog-do-db の影響がステートメントベースまたは行ベースのいずれのロギングが使用されているかによって異なるのと同じです。

    ステートメントベースのロギング --database オプションは次のように機能します。

    • db_name がデフォルトデータベースである間、ステートメントは db_name または別のデータベースのテーブルを修正する場合でも出力されます。

    • db_name がデフォルトデータベースとして選択されていない場合は、db_name のテーブルを修正する場合でもステートメントは出力されません。

    • CREATE DATABASEALTER DATABASE、および DROP DATABASE は例外です。ステートメントを出力するかどうかを判断するときには、作成、変更、または削除されたデータベースがデフォルトのデータベースであるとみなされます。

    これらのステートメントを実行することによって、ステートメントベースのロギングを使用してバイナリログが作成されたとします。

    INSERT INTO test.t1 (i) VALUES(100);
    INSERT INTO db2.t2 (j)  VALUES(200);
    USE test;
    INSERT INTO test.t1 (i) VALUES(101);
    INSERT INTO t1 (i)      VALUES(102);
    INSERT INTO db2.t2 (j)  VALUES(201);
    USE db2;
    INSERT INTO test.t1 (i) VALUES(103);
    INSERT INTO db2.t2 (j)  VALUES(202);
    INSERT INTO t2 (j)      VALUES(203);
    

    デフォルトデータベースがないため、mysqlbinlog --database=test は最初の 2 つの INSERT ステートメントを出力しません。USE test に続く 3 つの INSERT ステートメントは出力しますが、USE db2 に続く 3 つの INSERT ステートメントは出力しません。

    デフォルトデータベースがないため、mysqlbinlog --database=db2 は最初の 2 つの INSERT ステートメントを出力しません。USE test に続く 3 つの INSERT ステートメントは出力しませんが、USE db2 に続く 3 つの INSERT ステートメントは出力します。

    行ベースのロギング mysqlbinlog は、db_name に属するテーブルを変更するエントリのみを出力します。これにはデフォルトのデータベースには影響しません。今説明したバイナリログが、ステートメントベースのロギングではなく行ベースのロギングを使用して作成されたとします。mysqlbinlog --database=test は、USE が発行されたか、またはデフォルトのデータベースが何かにかかわらず、テストデータベースの t1 を変更するエントリのみを出力します。

    サーバーが、binlog_formatMIXED に設定された状態で稼働していて、mysqlbinlog--database オプションで使用できるようにする場合、変更されるテーブルが USE で選択されたデータベースであることを保証する必要があります。(特に、クロスデータベースの更新は使用しないようにしてください。)

    MySQL 5.6.10 より前では、GTID が有効な MySQL サーバーによって書き出されたログでは、--database オプションは正しく機能しませんでした。(Bug#15912728)

  • --debug[=debug_options], -# [debug_options]

    デバッグのログを書き込みます。一般的な debug_options 文字列は d:t:o,file_name です。デフォルトは d:t:o,/tmp/mysqlbinlog.trace です。

  • --debug-check

    プログラムの終了時に、デバッグ情報を出力します。

  • --debug-info

    プログラムの終了時に、デバッグ情報とメモリーおよび CPU 使用率の統計を出力します。

  • --default-auth=plugin

    使用するクライアント側の認証プラグイン。セクション6.3.7「プラガブル認証」を参照してください。

    このオプションは MySQL 5.6.2 で追加されました。

  • --defaults-extra-file=file_name

    このオプションファイルは、グローバルオプションファイルのあとに読み取りますが、(UNIX では) ユーザーオプションファイルの前に読み取るようにしてください。ファイルが存在しないかアクセスできない場合、エラーが発生します。file_name は、フルパス名でなく相対パス名として指定された場合、現行ディレクトリを基準にして解釈されます。

  • --defaults-file=file_name

    指定されたオプションファイルのみ使用します。ファイルが存在しないかアクセスできない場合、エラーが発生します。file_name は、フルパス名でなく相対パス名として指定された場合、現行ディレクトリを基準にして解釈されます。

  • --defaults-group-suffix=str

    通常のオプショングループだけでなく、通常の名前に str のサフィクスが付いたグループも読み取ります。たとえば、mysqlbinlog は通常 [client] グループおよび [mysqlbinlog] グループを読み取ります。--defaults-group-suffix=_other オプションを指定した場合、mysqlbinlog[client_other] グループおよび [mysqlbinlog_other] グループも読み取ります。

  • --disable-log-bin, -D

    バイナリロギングを無効化します。これは、--to-last-log オプションを使用して同じ MySQL サーバーに対して出力を送信している場合、無限ループを回避するのに便利です。このオプションは、クラッシュ後、すでにログに記録したステートメントの重複を回避するのにも便利です。

    このオプションには SUPER 権限を保持していることが必要です。mysqlbinlog が、出力に SET sql_log_bin = 0 ステートメントを含め、そのあとの出力のバイナリロギングを無効にするようになります。SET ステートメントは、SUPER 権限がない場合は効果がありません。

  • --exclude-gtids=gtid_set

    gtid_set にリストされたグループを表示しません。MySQL 5.6.5 で追加されました。

  • --force-if-open, -F

    バイナリログファイルが開いているか適切に閉じられていない場合でも読み取ります。

  • --force-read, -f

    このオプションでは、mysqlbinlog が認識できないバイナリログイベントを読み取った場合に、警告を出力し、イベントを無視して続行します。このオプションを使用しない場合は、mysqlbinlog はそのようなイベントを読み取ると停止します。

  • --hexdump, -H

    セクション4.6.8.1「mysqlbinlog 16 進ダンプ形式」に説明されているように、ログの 16 進ダンプをコメントに表示します。16 進出力はレプリケーションのデバッグに便利な場合があります。

  • --host=host_name, -h host_name

    指定されたホストの MySQL サーバーからバイナリログを取得します。

  • --include-gtids=gtid_set

    gtid_set にリストされたグループのみを表示します。MySQL 5.6.5 で追加されました。

  • --local-load=path, -l path

    指定されたディレクトリに LOAD DATA INFILE 用のローカル一時ファイルを準備します。

    重要

    これらの一時ファイルは、mysqlbinlog およびその他のどの MySQL プログラムによっても自動的に削除されません。

  • --login-path=name

    指名されたログインパスから .mylogin.cnf ログインファイルのオプションを読み取ります。ログインパスは、hostuser、および password という限定されたオプションのセットのみを許可するオプショングループです。ログインパスは、サーバーホストおよびそのサーバーで認証するための認証情報を示す値のセットであると考えてください。ログインパスファイルを作成するには、mysql_config_editor ユーティリティーを使用します。セクション4.6.6「mysql_config_editor — MySQL 構成ユーティリティー」を参照してください。このオプションは MySQL 5.6.6 で追加されました。

  • --no-defaults

    オプションファイルを読み取りません。オプションファイルから不明のオプションを読み取ることが原因でプログラムの起動に失敗する場合、--no-defaults を使用して、オプションを読み取らないようにできます。

    例外として、.mylogin.cnf ファイルは、存在する場合はすべての場合に読み取られます。これにより、--no-defaults が使用された場合にも、コマンド行よりも安全な方法でパスワードを指定できます。(.mylogin.cnfmysql_config_editor ユーティリティーによって作成されます。セクション4.6.6「mysql_config_editor — MySQL 構成ユーティリティー」を参照してください)。

  • --offset=N, -o N

    ログの最初の N 個のエントリをスキップします。

  • --password[=password], -p[password]

    サーバーに接続する際に使用するパスワードです。短いオプション形式 (-p) を使用した場合は、オプションとパスワードの間にスペースを置くことはできません。コマンド行で、--password オプションまたは -p オプションに続けて password の値を指定しなかった場合、mysqlbinlog はそれを要求します。

    コマンド行でパスワードを指定することはセキュアでないとみなすべきです。セクション6.1.2.1「パスワードセキュリティーのためのエンドユーザーガイドライン」を参照してください。オプションファイルを使用すれば、コマンド行でパスワードを指定することを回避できます。

  • --plugin-dir=path

    プラグインを検索するディレクトリ。--default-auth オプションを使用して認証プラグインを指定したが、mysqlbinlog がそれを検出できない場合は、このオプションを指定しなければならない可能性があります。セクション6.3.7「プラガブル認証」を参照してください。

    このオプションは MySQL 5.6.2 で追加されました。

  • --port=port_num, -P port_num

    リモートサーバーへの接続に使用する TCP/IP ポート番号。

  • --print-defaults

    プログラム名と、オプションファイルから受け取るすべてのオプションを出力します。

  • --protocol={TCP|SOCKET|PIPE|MEMORY}

    サーバーへの接続に使用する接続プロトコル。このオプションは、ほかの接続パラメータによって、必要なプロトコル以外のものが通常使用される場合に役立ちます。許可される値の詳細は、セクション4.2.2「MySQL サーバーへの接続」を参照してください。

  • --raw

    デフォルトでは、mysqlbinlog はバイナリログファイルを読み取り、イベントをテキスト形式で書き出します。--raw オプションは mysqlbinlog に対して、元のバイナリ形式で書き出すことを指示します。ファイルはサーバーから要求されるため、これを使用するには、--read-from-remote-server も使用する必要があります。mysqlbinlog はサーバーから読み取った各ファイルに対して 1 つの出力ファイルを書き出します。--raw オプションは、サーバーのバイナリログのバックアップを作成するために使用できます。--stop-never オプションを使用すると、mysqlbinlog はサーバーに接続されたままになるため、バックアップはライブです。デフォルトでは、出力ファイルは現在のディレクトリに元のログファイルと同じ名前で書き出されます。出力ファイル名は --result-file オプションを使用して変更できます。詳細は、セクション4.6.8.3「バイナリログファイルのバックアップのための mysqlbinlog の使用」を参照してください。

    このオプションは MySQL 5.6.0 で追加されました。

  • --read-from-remote-master=type

    COM_BINLOG_DUMP コマンドまたは COM_BINLOG_DUMP_GTID コマンドで、オプション値をそれぞれ BINLOG-DUMP-NON-GTIDS または BINLOG-DUMP-GTIDS に設定して、MySQL サーバーからバイナリログを読み取ります。--read-from-remote-master=BINLOG-DUMP-GTIDS--exclude-gtids と組み合わされると、トランザクションをマスターでフィルタでき、不要なネットワークトラフィックを防ぐことができます。

    --read-from-remote-server の説明も参照してください。

    このオプションは MySQL 5.6.5 で追加されました。

  • --read-from-remote-server, -R

    バイナリログをローカルログファイルからではなく MySQL サーバーから読み取ります。次のオプションも指定されていないかぎり、接続パラメータオプションはすべて無視されます。これらのオプションは --host--password--port--protocol--socket、および --user です。

    このオプションでは、リモートサーバーが稼働していることが必要です。リモートサーバー上のバイナリログファイルに対してのみ機能します。リレーログファイルには機能しません。

    MySQL 5.6.5 では、このオプションは --read-from-remote-master=BINLOG-DUMP-NON-GTIDS と同様です。

  • --result-file=name, -r name

    --raw オプションがない場合は、このオプションは mysqlbinlog がテキスト出力を書き出すファイルを示します。--raw がある場合は、mysqlbinlog はサーバーから転送される各ログファイルに対して 1 つのバイナリ出力ファイルを、デフォルトでは現在のディレクトリに元のログファイルと同じ名前で書き出します。この場合、--result-file オプションの値は出力ファイル名を変更するプリフィクスとして処理されます。

  • --secure-auth

    古い (4.1 より前の) 形式でサーバーにパスワードを送信しません。これにより、新しいパスワード形式を使用するサーバー以外への接続を防ぎます。このオプションはデフォルトで有効です。無効にするには --skip-secure-auth を使用します。このオプションは MySQL 5.6.17 で追加されました。

    注記

    4.1 以前のハッシュ方式を使用するパスワードはネイティブのパスワードハッシュ方式を使用するパスワードよりもセキュアでないため、使用しないようにしてください。4.1 よりも前のパスワードは非推奨であり、これらのサポートは今後の MySQL リリースで削除される予定です。アカウントのアップグレード手順については、セクション6.3.8.3「4.1 よりも前のパスワードハッシュ方式と mysql_old_password プラグインからの移行」を参照してください。

  • --server-id=id

    指定されたサーバー ID を持つサーバーによって作成されたイベントのみを表示します。

  • --server-id-bits=N

    サーバーを特定するために、server_id の最初の N ビットのみを使用します。server-id-bits が 32 未満にセットされ、ユーザーデータが最上位ビットに保存される mysqld によってバイナリログが書き出された場合、--server-id-bits を 32 にセットして mysqlbinlog を実行するとこのデータを表示できます。

    このオプションは、MySQL Cluster 配布で提供されるバージョン、または MySQL Cluster ソースからビルドされた mysqlbinlog によってのみサポートされます。

  • --set-charset=charset_name

    SET NAMES charset_name ステートメントを出力に追加して、ログファイルの処理に使用される文字セットを指定します。

  • --shared-memory-base-name=name

    Windows で、共有メモリーを使用して作成されるローカルサーバーへの接続の共有メモリー名。デフォルト値は MYSQL です。共有メモリー名では大文字と小文字を区別します。

    共有メモリー接続を可能にするには、サーバーは --shared-memory オプションで起動する必要があります。

  • --short-form, -s

    追加情報および行ベースのイベントなしで、ログに含まれるステートメントのみを表示します。これはテスト専用で、本番環境のシステムで使用するべきではありません。

  • --skip-gtids[=(true|false)]

    出力に GTID を表示しません。これは、次の例に示すように GTID を含む 1 つまたは複数のバイナリログからダンプファイルに書き出す場合に必要です。

    shell> mysqlbinlog --skip-gtids binlog.000001 >  /tmp/dump.sql
    shell> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
    shell> mysql -u root -p -e "source /tmp/dump.sql"
    

    そうでない場合には、このオプションを本番環境で使用することは、通常推奨されません。

    このオプションは MySQL 5.6.5 で追加されました。

  • --socket=path, -S path

    localhost への接続用に使用する、Unix ソケットファイル、または Windows では使用する名前付きパイプの名前。

  • --start-datetime=datetime

    datetime 引数と同じかそれより遅いタイムスタンプを持つ最初のイベントから、バイナリログの読み取りを始めます。datetime 値は、mysqlbinlog を実行するマシンのローカルタイムゾーンに相対的です。値は DATETIME または TIMESTAMP データ型に受け付けられる形式にしてください。例:

    shell> mysqlbinlog --start-datetime="2005-12-25 11:25:56" binlog.000003
    

    このオプションはポイントインタイムリカバリに便利です。セクション7.3「バックアップおよびリカバリ戦略の例」を参照してください。

  • --start-position=N, -j N

    N 以上の位置を持つ最初のイベントから、バイナリログの読み取りを始めます。このオプションはコマンド行で最初に指名されたログファイルに適用されます。

    このオプションはポイントインタイムリカバリに便利です。セクション7.3「バックアップおよびリカバリ戦略の例」を参照してください。

  • --stop-datetime=datetime

    datetime 引数と同じかそれより遅いタイムスタンプを持つ最初のイベントで、バイナリログの読み取りを終了します。このオプションはポイントインタイムリカバリに便利です。datetime 値の詳細については、--start-datetime オプションの説明を参照してください。

    このオプションはポイントインタイムリカバリに便利です。セクション7.3「バックアップおよびリカバリ戦略の例」を参照してください。

  • --stop-never

    このオプションは --read-from-remote-server とともに使用されます。mysqlbinlog に対して、サーバーに接続したままの状態を保つことを指示します。そうしないと、mysqlbinlog は最後のログファイルがサーバーから転送された時点で終了します。--stop-never は暗黙的に --to-last-log を指定するため、コマンド行で指名する必要があるのは転送される最初のログファイルのみです。

    --stop-never は一般的に、ライブバイナリログバックアップを作成するために --raw とともに使用されますが、--raw なしで使用して、サーバーがログイベントを生成するに従ってそれらを継続的にテキスト表示することも可能です。

    このオプションは MySQL 5.6.0 で追加されました。

  • --stop-never-slave-server-id=id

    --stop-never を使用すると、mysqlbinlog はサーバーに接続する際にサーバー ID の 65535 をレポートします。--stop-never-slave-server-id はレポートするサーバー ID を明示的に指定します。スレーブサーバーまたは別の mysqlbinlog プロセスの ID との競合を避けるために使用できます。セクション4.6.8.4「mysqlbinlog サーバー ID の指定」を参照してください。

    このオプションは MySQL 5.6.0 で追加されました。

  • --stop-position=N

    N 以上の位置を持つ最初のイベントで、バイナリログの読み取りを終了します。このオプションは、コマンド行で最後に指名されたログファイルに適用されます。

    このオプションはポイントインタイムリカバリに便利です。セクション7.3「バックアップおよびリカバリ戦略の例」を参照してください。

  • --to-last-log, -t

    MySQL サーバーから要求されたバイナリログの最後で終了せず、最後のバイナリログの最後まで続けて出力します。同じ MySQL サーバーに出力を送信した場合、無限ループになる場合があります。このオプションには --read-from-remote-server が必要です。

  • --user=user_name, -u user_name

    リモートサーバーへの接続時に使用する MySQL ユーザー名。

  • --verbose, -v

    行イベントを再構築し、コメント化された SQL ステートメントとして表示します。このオプションを 2 回指定すると、出力にはカラムデータ型と一部のメタデータを示すコメントが含まれます。

    --base64-output および --verbose の行イベント出力への影響を示す例は、セクション4.6.8.2「mysqlbinlog 行イベントの表示」を参照してください。

  • --verify-binlog-checksum, -c

    バイナリログファイルのチェックサムを検証します。このオプションは MySQL 5.6.1 で追加されました。

  • --version, -V

    バージョン情報を表示して終了します。

    MySQL 5.6.11 より前では、表示される mysqlbinlog のバージョン番号は 3.3 でした。MySQL 5.6.11 以降では 3.4 です。(Bug #15894381、Bug #67643)

--var_name=value 構文を使用して、次の変数を設定することもできます。

  • open_files_limit

    予約するオープンファイルディスクリプタの数を指定します。

mysqlbinlog の出力を mysql クライアントにパイプして、バイナリログに含まれるイベントを実行できます。このテクニックは、古いバックアップがある場合にクラッシュからリカバリするために使用されます (セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください)。例:

shell> mysqlbinlog binlog.000001 | mysql -u root -p

または:

shell> mysqlbinlog binlog.[0-9]* | mysql -u root -p

mysqlbinlog が生成したステートメントに BLOB 値が含まれる可能性がある場合、mysql がそれらを処理するときに問題が生じることがあります。この場合は、mysql--binary-mode オプションで起動します。

ステートメントログをまず変更する必要がある場合 (たとえば、何らかの理由で実行しないステートメントを削除するなど) は、代わりに mysqlbinlog の出力をテキストファイルにリダイレクトすることもできます。ファイルの編集後、mysql プログラムへの入力として使用することによって、そこに含まれるステートメントを実行します。

shell> mysqlbinlog binlog.000001 > tmpfile
shell> ... edit tmpfile ...
shell> mysql -u root -p < tmpfile

mysqlbinlog は、--start-position オプションで起動された場合、バイナリログ内のオフセットが指定された位置以上のイベントのみを表示します (指定された位置は 1 つのイベントの開始位置に一致していなければなりません)。指定された日付と時間を持つイベントを検出したときに停止および起動するオプションもあります。これにより、--stop-datetime オプションを使用してポイントインタイムリカバリが実行できます (たとえば、データベースを今日の 10:30 am 現在の状態までロールバックするといったことが可能になります)。

MySQL サーバーに実行する複数のバイナリログがある場合、安全な方法は、サーバーへの 1 つの接続を使用して、それらすべてを処理することです。これは、安全でない可能性があることを示す例です。

shell> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
shell> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!

サーバーに対してこのように複数の接続を使用してバイナリログを処理する場合、最初のログファイルに CREATE TEMPORARY TABLE ステートメントが含まれており、2 番目のログには一時テーブルを使用するステートメントが含まれていると、問題が発生します。最初の mysql プロセスが終了すると、サーバーは一時テーブルを削除します。2 番目の mysql プロセスでテーブルの使用を試みると、サーバーは不明なテーブルと報告します。

このような問題を回避するには、1 つmysql プロセスを使用して、処理するすべてのバイナリログの内容を実行します。これはそれを実行する 1 つの方法です。

shell> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

もう 1 つのアプローチは、すべてのログを 1 つのファイルに書き込み、次にそのファイルを処理することです。

shell> mysqlbinlog binlog.000001 >  /tmp/statements.sql
shell> mysqlbinlog binlog.000002 >> /tmp/statements.sql
shell> mysql -u root -p -e "source /tmp/statements.sql"

mysqlbinlog は、元のデータファイルなしで LOAD DATA INFILE 操作を再現する出力を生成できます。mysqlbinlog はデータを一時ファイルにコピーし、そのファイルを参照する LOAD DATA LOCAL INFILE ステートメントを書き出します。これらのファイルが書き出されるディレクトリのデフォルトの場所はシステムごとに異なります。ディレクトリを明示的に指定するには、--local-load オプションを使用します。

mysqlbinlogLOAD DATA INFILE ステートメントを LOAD DATA LOCAL INFILE ステートメントに変換するため (つまり、LOCAL を追加します)、ステートメントの処理に使用するクライアントとサーバーの両方が、LOCAL 機能を有効にして構成されていなければなりません。セクション6.1.6「LOAD DATA LOCAL のセキュリティーの問題」を参照してください。

警告

LOAD DATA LOCAL ステートメント用に作成された一時ファイルは、これらのステートメントをユーザーが実際に実行するまで必要なため、自動的には削除されません。ステートメントログが必要なくなった時点で、ユーザーが一時ファイルを削除するようにしてください。これらのファイルは一時ファイルディレクトリに存在し、original_file_name-#-# といった名前が付いています。


User Comments
  Posted by Tom Mulkins on September 23, 2003
I had some problems using mysqlbinlog with temporary files. It would have helped to have an explanation above but here is a brief example:

mysqlbinlog -d mydb -r mydb.sql mydb-bin.001

/*The above command will create a file called mydb.sql in my CWD(current working directory) with queries extracted from binary log mydb-bin.001 for mydb database queries only*/

Now say I had some load data infile statements in my binary log. If my /tmp directory did not contain those files mysqbinlog would create them for me. Here's th problem, if the file aready exists mysqlbinlog will error out with message File: 'tmp/XXX.csv' not found. Yet if you look in your /tmp directory there it is! Don't panic...mysqlbinlog won't write over an existing file and there is no flag to do so (in my opinion there should be that option).

Now you could delete the files from your /tmp directory and et mysqlbinlog recreate them for you but it is simpler to create a tmp directory in your CWD like this:

mkdir tmp

Now use the mysqlbinlog flag --local-load to specify your CWD/tmp directory to WRITE the files like this:

mysqlbinlog -d mydb -r mydb.sql --local-load="tmp/" mydb-bin.001

Your files will be created in CWD/tmp. Should you need to run the mysqlbinlog utilty again just rm CWD/tmp/* and run the utility again.

Hope this helps,
Tom
  Posted by KEvin on February 9, 2005
Some things to know about mysqlbinlog which did not strike me as obvious (also it is hinted by the doc) :

--read-from-remote-server :
1) with this option you can only read files present in binary_log-bin.index on the master so you cannot read relay log files on the distant server
2) the distant mysql server must be up (you cannot just read the distant files), so it loses much of its utility : if the distant master is up you can "start slave" or "change master to MASTER_LOG_FILE=...".
But if the master is down and you want to get the latest changes you must copy the remote (with scp for example) binary logs and then run mysqlbinlog locally ...

--start-position (or --position) :
1) it must be the exact position of an event.
2) it is the first position that will be read so you must not use the "Read_Master_Log_Pos" (as shown by "show slave status") which is the position of the last event done.
You have to use :
--start-position=Read_Master_Log_Pos --offset=1 Master_Log_File
to skip the first event.
As Read_Master_Log_Pos is one of the most easy position to get it is a pity that you have to specify the offset each time...

  Posted by john danilson on September 8, 2006
I found the --start-datetime and --stop-datetime to be finicky about the format. While yyyy-mm-dd hh:mm:ss work fine elsewhere, this expected yy-mm-dd hh:mm:ss to work.
  Posted by Yiannis Mavridis on April 30, 2007
Regarding KEvin
--start-position (or --position) :
1) it must be the exact position of an event.
2) it is the first position that will be read so you must not use the "Read_Master_Log_Pos" (as shown by "show slave status") which is the position of the last event done.
You have to use :
--start-position=Read_Master_Log_Pos --offset=1 Master_Log_File
to skip the first event.
As Read_Master_Log_Pos is one of the most easy position to get it is a pity that you have to specify the offset each time...

I tested and i found that you do not need to use the offset=1 like KEvin is saying above, because the exec_master_log_pos on the 'show slave status' view contains the next not yet executed command of the binlog
  Posted by Baron Schwartz on December 13, 2007
On Linux, you can use -l /dev/null to avoid the temp files if you're just looking through the output. mysqlbinlog will complain, but it won't create the file and it won't create the corresponding LOAD DATA INFILE statement (because it couldn't create the file).

This is useful if your log files have a lot of very large LOAD DATA INFILE statements, and you don't want to incur the overhead of writing them to disk and then deleting them.
  Posted by Jason Ho on August 19, 2008
If the sql generated by mysqlbinlog is not processed by mysql, this could be the root cause:

http://bugs.mysql.com/bug.php?id=34541
(And that you have configured your server to execute "set autocommit=0" on client connect.)

An indication is that the mysql client complains on this line:

SET /*!*/;

A workaround would be replacing the bad line:

mysqlbinlog mysql-bin.000011 | sed -e 's/SET \/\*\!\*\//SET AUTOCOMMIT=0/g' | mysql
  Posted by Jim Grill on September 19, 2008
This may seem obvious but I had to help someone with this...

If you use the --start-datetime= option and you have a large binlog, be patient. It may take a while to return results. Don't hit control+c thinking it's broken or something. Just wait patiently for what you're looking for to be found.
  Posted by Phillip Gee on March 11, 2009
Yiannis Mavridis is right.

Don't listen to KEvin and use the --offset=1 switch, it will miss the first command. If there's only been one command since the downtime then you won't be updating your slave.

Caused me a world of pain listening to this while testing.
Sign Up Login You must be logged in to post a comment.