Skip navigation links
MySQL 5.1 リファレンスマニュアル :: 7 クライアントプログラムとユーティリティ プログラム :: 7.10 mysqlbinlog — バイナリログファイルを処理するためのユーティリティ
7.11 mysqlcheck — テーブル メンテナンスと修復プログラム »
Section Navigation      [Toggle]

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

サーバが生成するバイナリログファイルはバイナリフォーマットで書かれています。これらのファイルをテキストフォーマットで確認するには、mysqlbinlogユーティリティを使用してください。それに加えて、複製セットアップ内のスレーブサーバによって書き出されたリレイログファイルを読み取るのにmysqlbinlogを使用することもできます。リレイログはバイナリログファイルと同じフォーマットです。

mysqlbinlogは以下のように起動してください。 

shell> mysqlbinlog [options] log_file ...

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

shell> mysqlbinlog binlog.0000003

出力にはbinlog.000003内の全てのイベントが含まれています。イベント情報は実行されたステートメント、実行に必要な時間、発行したクライアントのスレッドID、実行時のタイムスタンプ等が含まれています。

ログ内にステートメントを再付加するためにmysqlbinlogの出力は再実行することができます(例えば、mysqlの入力として使用することで)。これはサーバがクラッシュした再のリカバリオペレーションとして便利にです。他の使用例は、後にこのセクションに登場するディスカッションを参照してください。

通常、バイナリログファイルを直接読み取りにmysqlbinlog使用し、ローカルMySQLサーバに付加します。--read-from-remote-serverオプションを使用してリモートサーバからバイナリログを読み取ることも可能です。リモートバイナリログを読み取る場合、接続パラメータオプションを提供することでどのようにしてサーバと接続すればよいか示しています。これらのオプションは--host、--password、--port、--protocol, --socket、と--userになります。--read-from-remote-serverオプションを使用した場合以外では、無視されます。

バイナリログやリレイログは項4.11.4. 「バイナリ ログ」と項5.5.5. 「レプリケーション リレーとステータス ファイル」でさらに詳細を参照することができます。

mysqlbinlogは次のオプションをサポートします。

  • --help, -?

    ヘルプ メッセージを表示し、閉じます。

  • --base64-output

    ベース64 エンコードを使用して全てのバイナリログエントリをプリントします。.これはデバッグ専用です。このオプションを使用して生成したログはプロダクションシステムには付加すべきではありません。このオプションはMySQL 5.1.5．で追加されました。

  • --character-sets-dir=path

    キャラクタ セットがインストールされるディレクトリです。項4.10.1. 「データおよびソート用キャラクタ セット」 を参照してください。

  • --database=db_name, -d db_name

    このデータベース（ローカルログのみ）のエントリをリストします。このオプションを使用することで１つのデータベースのみを指定することができます。複数の--databaseオプションを指定した場合、最後のオプションのみ使用されます。このオプションはmysqlbinlogに、デフォルトデータベースの場所からバイナリログのエントリを出力するよう強制します。(つまり、USEに選択された)db_name。これによって、異なるデータベースやデータベース自体を選択せずとも、UPDATE some_db.some_table SET foo='bar'といったクロスデータベースステートメントを複製しません。

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

    デバッグのログを書き込みます。debug_options文字列は大抵'd:t:o,file_name'になります。

  • --disable-log-bin, -D

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

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

  • --force-read, -f

    このオプションでは、mysqlbinlogが認識でき名いバイナリログイベントを読み込んだ場合、警告をプリント、イベントを無視し続行します。このオプションなしでは、mysqlbinlogはそのようなイベントを読み込んだ時点で停止します。

  • --hexdump, -H

    コメントでログの16進法ダンプを表示します。この出力は複製デバッグの際に便利です。16進法ダンプフォーマットは後ほどこのセクションで説明されています。このオプションはMySQL 5.1.2.で追加されました。

  • --host=host_name, -h host_name

    あるホストでMySQLサーバからバイナリログを取得する。

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

    特定のディレクトリ内からLOAD DATA INFILEのローカルテンポラリファイルを準備する。

  • --offset=N, -o N

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

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

    サーバに接続する際使用するパスワードです。ショートオプションフォーム(-p)を使用した場合、オプションとパスワードの間にスペースを置くことはできません。コマンドライン上で--password あるいは-pに続くオプションからpassword値を取り除いた場合、パスワード値を求められます。

    コマンドライン上でのパスワードの特定は安全ではありません。項4.8.6. 「パスワードのセキュリティ」 を参照してください。

  • --port=port_num, -P port_num

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

  • --position=N, -j N

    Deprecated.代わりに--start-positionを使用してください。

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

    使用するべき接続プロトコルです。

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

    バイナリログをローカルファイルから読み取らずにMySQLサーバから読み取ります。このオプションも提供されていない限りどの接続パラメータオプションも無視されます。これらのオプションは--host、--password、--port、--protocol、--socket、そして--userになります。

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

    提供されているファイルに出力を導きます。

  • --server-id=id

    特定のサーバIDを持つサーバによってのみ作成されたイベントだけを抽出します。このオプションはMySQL 5.1.4.以降から提供されています。

  • --set-charset=charset_name

    ログファイルの処理のために使用する文字列を特定するため、出力にSET NAMES charset_name ステートメントを追加してください。このオプションはMySQL 5.1.12.で追加されました。

  • --short-form, -s

    ログに含まれるステートメントのみを表示します。

  • --socket=path, -S path

    localhostの接続用に使用する、ユニックスではソケットファイル、Windowsでは使用する名づけられたパイプ。

  • --start-datetime=datetime

    datetimeアーギュメントと等価、もしくは遅いタイムスタンプを持つ最初のイベントからバイナリログの読み取りを始めます。datetime値はmysqlbinlogを作動させた場合、ローカルタイムゾーンに相対的です。値はDATETIMEやTIMESTAMPデータ型に受け付けられるフォーマットでなければいけません。例: 

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

    このオプションはpoint-in-timeリカバリを使用する際便利です。項4.9.2. 「バックアップとリカバリ手法の例示」 を参照してください。

  • --stop-datetime=datetime

    datetimeアーギュメントと等価、もしくは遅いタイムスタンプを持つ最初のイベントからバイナリログの読み取りを停止します。このオプションはpoint-in-timeリカバリを使用する際便利です。datetime値に関する詳細については--start-datetimeオプションの説明を参照してください。

  • --start-position=N

    Nアーギュメントと等価、もしくは遅いタイムスタンプを持つ最初のイベントからバイナリログの読み取りを始めます。このオプションはコマンドライン上で最初に名づけられるログファイルに対してのみ適用されます。

  • --stop-position=N

    Nアーギュメントと等価、もしくは遅いタイムスタンプを持つ最初のイベントからバイナリログの読み取りを停止します。このオプションはコマンドライン上で最後に名づけられるログファイルに対してのみ適用されます。

  • --to-last-log, -t

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

  • --user=user_name, -u user_name

    リモートサーバに接続する際使用するMySQLユーザ名です。

  • --version, -V

    バージョン情報を表示し、閉じます。

--var_name=value 構文を使用することで以下の構文をセットすることができます。

  • open_files_limit

    リザーブするオープンファイルディスクリプタの数を特定します。

--set-variable=var_name=value or -O var_name=value構文を使用することで、変数をセットすることも可能です。構文は反対語となっています。.

mysqlbinlogの出力をmysqlクライアントにパイプすることができます。 これはバイナリログに含まれるステートメントを実行するために行います。バックアップが古い(項4.9.1. 「データベースのバックアップ」を参照してください)場合、クラッシュからのリカバーに使用します。例: 

shell> mysqlbinlog binlog.000001 | mysql

または 

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

mysqlbinlogの出力をテキストファイルにリダイレクトすることもできます。これは、先にステートメントログを改良する必要がある場合に行います。(例えば、実行したくないステートメントを取り除かなければいけないときに)。ファイル編集後、mysqlプログラムの入力として使用することで含まれているステートメントを実行してください。

mysqlbinlogには--start-positionオプションがあります。ある特定のポジションよりも等価もしくは大きいオフセットを持つ、バイナリログ内のステートメントのみをプリントします(そのポジションは1つのイベントのスタートをマッチしなければいけません)。それはある特定の日付と時刻を与えられているイベントをスタート・ストップさせるオプションも有しています。これにより、--stop-datetimeオプションを使用してpoint in timeリカバリの実行を有効化します(例えば、「データベースを10:30分現在の状態まで巻き戻す」といったことが可能になります)。

MySQLサーバ上で1つ以上のバイナリログを実行しなければいけない場合、サーバに対して1つの接続で処理するのが安全です。以下に危険な例を示します。 

shell> mysqlbinlog binlog.000001 | mysql # DANGER!!
shell> mysqlbinlog binlog.000002 | mysql # DANGER!!

最初のログファイルにCREATE TEMPORARY TABLEステートメントが含まれており、2番目のログにはテンポラリテーブルを使用するステートメントが含まれている場合、サーバに対して異なる接続を使用してバイナリログを処理すると問題が発生します。最初のmysql処理が停止したとき、サーバはテンポラリテーブルをドロップします。2番目のmysql処理でテーブルの使用を試みると、サーバは「認識されていないテーブル」として報告します。

このような問題を回避するには、処理したいバイナリログの内容を実行するために１つの接続を使用してください。以下に１例を示します。 

shell> mysqlbinlog binlog.000001 binlog.000002 | mysql

また、ログを全て１つのファイルに書き込み、ファイルを処理するのも手です。 

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

mysqlbinlogはオリジナルデータファイルなしでLOAD DATA INFILEオペレーションを再生する出力を生成することができます。mysqlbinlogはデータをテンポラリファイルにコピーし、ファイルに関連するLOAD DATA LOCAL INFILEステートメントを書きます。これらのファイルが書かれているディレクトリ内のデフォルトロケーションはシステムごとに異なります。ディレクトリを明示的に指定したい場合は、--local-loadオプションを使用してください。

mysqlbinlogがLOAD DATA INFILEステートメントをLOAD DATA LOCAL INFILE ステートメントに変換するため、(つまり、LOCALを追加する)ステートメントの処理に使用するクライアントとサーバ双方がLOCAL機能を許容するようにコンフィギャされていなければいけません。項4.6.4. 「LOAD DATA LOCAL のセキュリティ関連事項」 を参照してください。

警告：LOAD DATA LOCALステートメント用に作成されたテンポラリファイルは、自動的には消去されません。これは、それらステートメントを実際に実行するまで必要になるからです。ステートメントログが必要なくなった時点でユーザがテンポラリファイルを消去する必要があります。これらのファイルはテンポラリファイルディレクトリに存在し、original_file_name-#-#といった名前がついています。

--hexdumpオプションはコメント内にログ内容の16進性ダンプを生成します。 

shell> mysqlbinlog --hexdump master-bin.000001

上記のコマンドを使用すれば、出力は以下の様になります。 

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1  end_log_pos 98
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags
# 00000004 9d fc 5c 43   0f   01 00 00 00   5e 00 00 00   62 00 00 00   00 00
# 00000017 04 00 35 2e 30 2e 31 35  2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43  13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b  00 04 1a                |.......K...|
#       Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
#       at startup
ROLLBACK;

16進性ダンプ出力は、現在以下のエレメントを含んでいます。このフォーマットは将来変更される可能性があります。

  • ポジション:ログファイル内のバイトポジション。

  • Timestamp:イベントのタイムスタンプ以下の例では、'9d fc 5c 43'は'051024 17:24:13'を16進変換で表します。

  • Type:ログイベントのタイプ以下の例では、'0f'は例のイベントがFORMAT_DESCRIPTION_EVENTであることを意味しています。以下のテーブルが可能なタイプをリストします。

    タイプ 名 意味
    00 UNKNOWN_EVENT このイベントはログ内に存在してはいけません。
    01 START_EVENT_V3 MySQL 4より前のバージョンによって書き出されたログファイルの始めを示しています。
    02 QUERY_EVENT 最も一般的なイベントのタイプです。これらはマスタで実行されるステートメントを含んでいます。
    03 STOP_EVENT マスタが停止したことを示しています。
    04 ROTATE_EVENT マスタが新しいログファイルにスイッチした際に書き出されます。
    05 INTVAR_EVENT 一般的に、AUTO_INCREMENT 値に対して使用されます。これは、LAST_INSERT_ID()関数がステートメントで使用されているときです。
    06 LOAD_EVENT MｙSQL3.23でLOAD DATA INFILE用に使用されます。
    07 SLAVE_EVENT 将来の使用のため保存されます。
    08 CREATE_FILE_EVENT LOAD DATA INFILE ステートメントに使用されます。これはそのようなステートメントの実行の始まりを示しています。スレーブ上でテンポラリファイルが作成されます。MySQL 4でのみ使用されています。
    09 APPEND_BLOCK_EVENT LOAD DATA INFILE ステートメントで使用されるデータを含んでいます。スレーブ上でデータがテンポラリファイル内に記憶されます。
    0a EXEC_LOAD_EVENT LOAD DATA INFILE ステートメントに使用されます。スレーブ上のテーブルにテンポラリファイルの内容が記憶されます。MySQL 4でのみ使用されています。
    0b DELETE_FILE_EVENT LOAD DATA INFILE ステートメントのロールバックです。テンポラリファイルはスレーブ上で消去されます。
    0c NEW_LOAD_EVENT LOAD DATA INFILEMySQL 4以前のバージョンで使用されます。
    0d RAND_EVENT RAND()関数がステートメントで使用されている場合、ランダム値の情報を送信するのに使用されます。
    0e USER_VAR_EVENT ユーバ変数の複製に使用されます。
    0f FORMAT_DESCRIPTION_EVENT MySQL 5かそれ以降のバージョンで書き出されたログファイルの始まりを示しています。
    10 XID_EVENT XAトランザクションのコミットを示すイベントです。
    11 BEGIN_LOAD_QUERY_EVENT MySQL 5以降のバージョンでLOAD DATA INFILEステートメントに使用されます。
    12 EXECUTE_LOAD_QUERY_EVENT MySQL 5以降のバージョンでLOAD DATA INFILEステートメントに使用されます。
    13 TABLE_MAP_EVENT テーブル定義の情報です。MySQL 5.1以降使用されています。
    14 WRITE_ROWS_EVENT 作成されるはずのシングルテーブルの行データです。MySQL 5.1以降使用されています。
    15 UPDATE_ROWS_EVENT 更新されるはずのシングルテーブルの行データです。MySQL 5.1以降使用されています。
    16 DELETE_ROWS_EVENT 消去されるはずのシングルテーブルの行データです。MySQL 5.1以降使用されています。

  • Master ID:イベントを作成したマスタのサーバIDです。

  • Size:イベントのサイズをバイトで表しています。

  • Master Pos:オリジナルマスタログファイル内のイベントのポジションです。.

  • Flags:16 フラッグ現在、以下のフラッグが使用されています。他のフラグは将来に向けて保存されています。

    フラグ 名 意味
    01 LOG_EVENT_BINLOG_IN_USE_F ログファイルは完全に閉じています。(FORMAT_DESCRIPTION_EVENTでのみ使用されています。)このフラグがセットされている場合(例えば、フラグがFORMAT_DESCRIPTION_EVENT内で'01 00'の場合) ログファイルは完全には閉じられていません。マスタがクラッシュしたことによる場合が最も可能性が高いです(例えば、停電などにより)。
    02   将来使用するために保存されています。
    04 LOG_EVENT_THREAD_SPECIFIC_F イベントが実行されたときの接続に依存している場合セットしてください(例えば、'04 00')。例えば、イベントがテンポラリテーブルを使用している場合。
    08 LOG_EVENT_SUPPRESS_USE_F イベントがデフォルトデータベースに対して依存していないケースではセットされることがあります。

    他のフラグは将来使用するために保存されています。