MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む

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

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

サーバーのバイナリログは、データベースの内容に対する変更を記述するイベントを含むファイルで構成されます。 サーバーはこれらのファイルをバイナリ形式で書き出します。 内容をテキスト形式で表示するには、mysqlbinlog ユーティリティーを使用します。 また、mysqlbinlog を使用して、複製設定で複製サーバーによって書き込まれたリレーログファイルの内容を表示することもできます。これは、リレーログの形式がバイナリログと同じであるためです。 バイナリログおよびリレーログは、セクション5.4.4「バイナリログ」およびセクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」でさらに説明します。

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

shell> mysqlbinlog [options] log_file ...

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

shell> mysqlbinlog binlog.0000003

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

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

# 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「Point-in-Time (増分) リカバリ」を参照してください。 mysqlbinlog で使用される内部使用 BINLOG ステートメントを実行するには、BINLOG_ADMIN 権限 (または非推奨の SUPER 権限) か、REPLICATION_APPLIER 権限と各ログイベントを実行するための適切な権限が必要です。

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

バイナリログファイルが暗号化されている場合 (MySQL 8.0.14 以降で実行可能)、mysqlbinlog はそれらを直接読み取ることはできませんが、--read-from-remote-server オプションを使用してサーバーから読み取ることができます。 バイナリログファイルは、サーバーの binlog_encryption システム変数が ON に設定されている場合に暗号化されます。 SHOW BINARY LOGS ステートメントは、特定のバイナリログファイルが暗号化されているか暗号化されていないかを示します。 暗号化されたバイナリログファイルと暗号化されていないバイナリログファイルは、暗号化されたログファイル (0xFD62696E) のファイルヘッダーの先頭にあるマジック番号を使用して区別することもできます。これは、暗号化されていないログファイル (0xFE62696E) に使用されるものとは異なります。 暗号化されたバイナリログファイルを直接読み取ろうとしたが、古いバージョンの mysqlbinlog がそのファイルをバイナリログファイルとして認識しない場合、MySQL 8.0.14 から適切なエラーが返されることに注意してください。 バイナリログの暗号化の詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。

バイナリログトランザクションペイロードが圧縮されている場合 (MySQL 8.0.20 以降で実行可能)、そのリリースの mysqlbinlog バージョンでは、トランザクションペイロードを自動的に解凍してデコードし、圧縮解除されたイベントと同様に出力します。 古いバージョンの mysqlbinlog では、圧縮されたトランザクションペイロードを読み取ることができません。 サーバー binlog_transaction_compression システム変数が ON に設定されている場合、トランザクションペイロードは圧縮され、単一のイベント (Transaction_payload_event) としてサーバーバイナリログファイルに書き込まれます。 --verbose オプションを使用すると、mysqlbinlog によって、使用される圧縮アルゴリズム、最初に受信された圧縮済ペイロードサイズ、および解凍後の結果のペイロードサイズを示すコメントが追加されます。

注記

圧縮されたトランザクションペイロードの一部である個々のイベントに対して mysqlbinlog が示す終了位置 (end_log_pos) は、元の圧縮されたペイロードの終了位置と同じです。 したがって、複数の解凍されたイベントの終了位置を同じにすることができます。

mysqlbinlog 独自の接続圧縮は、トランザクションペイロードがすでに圧縮されている場合は少なくなりますが、圧縮されていないトランザクションおよびヘッダーでは引き続き動作します。

バイナリログのトランザクション圧縮の詳細は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。

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

mysqlbinlog は、SQL ステートメントを実行する前に pseudo_slave_mode の値を true に設定します。 このシステム変数は、XA トランザクションの処理、original_commit_timestamp レプリケーション遅延タイムスタンプと original_server_version システム変数、およびサポートされていない SQL モードに影響します。

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

表 4.21 「mysqlbinlog のオプション」

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

mysqlbinlog の出力を mysql クライアントにパイプして、バイナリログに含まれるイベントを実行できます。 この方法は、古いバックアップがある場合に予期しない終了からリカバリするために使用されます (セクション7.5「Point-in-Time (増分) リカバリ」 を参照)。 例:

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"

MySQL 8.0.12 から、シェルパイプを使用して、ストリーム入力として複数のバイナリログファイルを mysqlbinlog に提供することもできます。 圧縮バイナリログファイルのアーカイブは、解凍して mysqlbinlog に直接提供できます。 この例では、binlog-files_1.gz に処理用の複数のバイナリログファイルが含まれています。 パイプラインは、binlog-files_1.gz の内容を抽出し、バイナリログファイルを標準入力として mysqlbinlog にパイプし、mysqlbinlog の出力を mysql クライアントにパイプして実行します:

shell> gzip -cd binlog-files_1.gz | ./mysqlbinlog - | ./mysql -uroot  -p

複数のアーカイブファイルを指定できます。次に例を示します:

shell> gzip -cd binlog-files_1.gz binlog-files_2.gz | ./mysqlbinlog - | ./mysql -uroot  -p

ストリーム入力の場合、mysqlbinlog はこのオプションを適用する最後のログファイルを識別できないため、--stop-position を使用しないでください。

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

mysqlbinlogLOAD DATA ステートメントを LOAD DATA LOCAL ステートメントに変換する (つまり、LOCAL を追加する) ため、ステートメントの処理に使用するクライアントとサーバーの両方で LOCAL 機能を有効にして構成する必要があります。 セクション6.1.6「LOAD DATA LOCAL のセキュリティー上の考慮事項」を参照してください。

警告

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