5.2.4 バイナリログ

5.2.4.1 バイナリロギング形式

5.2.4.2 バイナリログ形式の設定

5.2.4.3 混合形式のバイナリロギング形式

5.2.4.4 mysql データベーステーブルへの変更に対するロギング形式

バイナリログには、テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述する「イベント」が格納されます。また、行ベースのロギングが使用される場合を除き、(一致する行のない DELETE などの) 潜在的に変更を行おうとしたステートメントについてのイベントも格納されます。バイナリログには、データを更新した各ステートメントに要した時間に関する情報も格納されます。バイナリログには 2 つの重要な目的があります。

• レプリケーションについて、マスターレプリケーションサーバー上のバイナリログは、スレーブサーバーに送信されるデータ変更のレコードを提供します。マスターサーバーは、そのバイナリログに格納されているイベントをそのスレーブに送信し、スレーブはこれらのイベントを実行して、マスター上で実行されたものと同じデータ変更を実行します。セクション17.2「レプリケーションの実装」を参照してください。

• ある特定のデータリカバリ操作には、バイナリログの使用が必要です。バックアップがリストアされたあと、バックアップが実行されたあとに記録されたバイナリログ内のイベントが再実行されます。これらのイベントは、データベースをバックアップのポイントから最新の状態に持って行きます。セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください。

バイナリログは、データを変更しない SELECT や SHOW などのステートメントでは使用されません。(問題となるクエリーを特定するなどのために) すべてのステートメントをログに記録するには、一般クエリーログを使用します。セクション5.2.3「一般クエリーログ」を参照してください。

バイナリロギングを有効にしてサーバーを実行すると、パフォーマンスがいくらか低下します。ただし、レプリケーションをセットアップでき、リストア操作に対応できるというバイナリログの利点は、一般的にこのパフォーマンスの減少よりも重要です。

MySQL 5.6.2 以降では、バイナリログはクラッシュセーフになっています。完全なイベントまたはトランザクションのみがログに記録されたり、または読み戻されたりします。

MySQL 5.6.3 以降では、バイナリログに書き込まれるステートメントのパスワードはサーバーによって書き換えられ、文字どおりに平文で表示されることはありません。MySQL 5.6.3 より前では、ステートメント内のパスワードは書き換えられないため、バイナリログを保護するようにしてください。セクション6.1.2.3「パスワードおよびロギング」を参照してください。

次の説明では、バイナリロギングの操作に影響する一部のサーバーオプションおよび変数について記述します。完全なリストについては、セクション17.1.4.4「バイナリログのオプションと変数」を参照してください。

バイナリログを有効にするには、--log-bin[=base_name] オプションでサーバーを起動します。base_name 値が指定されない場合、デフォルト名は、pid-file オプションの値 (デフォルトではこれはホストマシンの名前) のあとに -bin が続きます。ベース名が指定される場合、別のディレクトリを指定する絶対パス名が前に付いたベース名が指定されないかぎり、サーバーはファイルをデータディレクトリに書き込みます。デフォルトのホスト名を使用せず、ベース名を明示的に指定することをお勧めします。その理由については、セクションB.5.8「MySQL の既知の問題」を参照してください。

ログ名に拡張子を指定した場合 (--log-bin=base_name.extension など)、拡張子は暗黙的に削除されて無視されます。

mysqld はバイナリログファイル名を生成するために、バイナリログベース名に数値拡張を付加します。数値はサーバーが新しいログファイルを作成するたびに増加し、順序付きの一連のファイルが作成されます。その一連のファイル内の新しいファイルは、サーバーが起動するかログをフラッシュするたびにサーバーによって作成されます。また、サーバーは現在のログのサイズが max_binlog_size に到達したあと、新しいバイナリログファイルを自動的に作成します。大きなトランザクションを使用する場合、トランザクションがひとまとまりでファイルに書き込まれて、複数のファイルに分割されないため、バイナリログファイルが max_binlog_size を超えることがあります。

使用されたバイナリログファイルの追跡を行うために、mysqld は、使用されたすべてのバイナリログファイルの名前を格納するバイナリログインデックスファイルも作成します。デフォルトでは、これはバイナリログファイルと同じベース名を持ち、拡張子 '.index' が付いています。バイナリログインデックスファイルの名前は、--log-bin-index[=file_name] オプションを使用して変更できます。mysqld の動作中にこのファイルを手動で変更しないでください。変更すると、mysqld を混乱させることになります。

「バイナリログファイル」という用語は一般的に、データベースイベントを格納する、番号付けされた個々のファイルを指します。「バイナリログ」という用語は、番号付けされたバイナリログファイルとインデックスファイルのセットをひとまとめにしたものを指します。

SUPER 権限を持つクライアントは、SET sql_log_bin=0 ステートメントを使用することによって、自分自身のステートメントのバイナリロギングを無効にすることができます。セクション5.1.4「サーバーシステム変数」を参照してください。

デフォルトでは、サーバーはイベント自体だけでなくイベントの長さもログに記録し、イベントが正しく書き込まれたことを検証するためにこれを使用します。また、binlog_checksum システム変数を設定することによって、サーバーがイベントのチェックサムを書き込むようにすることもできます。バイナリログから読み戻すとき、マスターはデフォルトではイベントの長さを使用しますが、master_verify_checksum システム変数を有効にすることによって、使用可能であればチェックサムを使用するように変更できます。スレーブ I/O スレッドも、マスターから受け取ったイベントを検証します。slave_sql_verify_checksum システム変数を有効にすることによって、リレーログから読み取るときにチェックサムが使用可能な場合、スレーブ SQL スレッドがチェックサムを使用するようにすることもできます。

バイナリログに記録されるイベントの形式は、バイナリロギング形式に依存します。行ベースのロギング、ステートメントベースのロギング、および混合ベースのロギングの 3 つのタイプの形式がサポートされます。使用されるバイナリロギング形式は、MySQL のバージョンに依存します。ロギング形式の一般的な説明については、セクション5.2.4.1「バイナリロギング形式」を参照してください。バイナリログの形式についての詳細な説明は、「MySQL Internals: The Binary Log」を参照してください。

サーバーは、--binlog-do-db および --binlog-ignore-db オプションを評価する際、それが --replicate-do-db および --replicate-ignore-db オプションを評価する場合と同じ方法で行います。これを行う方法については、セクション17.2.3.1「データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価」を参照してください。

レプリケーションスレーブサーバーは、デフォルトでは、レプリケーションマスターから受け取ったすべてのデータ変更を、それ自身のバイナリログに書き込みません。これらの変更をログに記録するには、--log-bin オプションに加えて --log-slave-updates オプションを指定してスレーブを起動します (セクション17.1.4.3「レプリケーションスレーブのオプションと変数」を参照してください)。これは、スレーブがチェーン型レプリケーションで、ほかのスレーブのマスターとしての役割も果たす場合に実行されます。

RESET MASTER ステートメントですべてのバイナリログファイルを削除したり、PURGE BINARY LOGS でそのサブセットを削除したりすることができます。セクション13.7.6.6「RESET 構文」およびセクション13.4.1.1「PURGE BINARY LOGS 構文」を参照してください。

レプリケーションを使用している場合、マスター上の古いバイナリログファイルを使用する必要があるスレーブがなくなったことを確認するまでは、それらのファイルを削除しないようにしてください。たとえば、スレーブが 3 日を超えて遅れて実行されることがない場合、mysqladmin flush-logs をマスター上で 1 日に 1 回実行し、3 日分よりも古いログを削除することができます。ファイルを手動で削除することができますが、PURGE BINARY LOGS を使用することが推奨され、この操作によってバイナリログインデックスファイルも安全に更新されます (さらに日付引数を使用できます)。セクション13.4.1.1「PURGE BINARY LOGS 構文」を参照してください。

mysqlbinlog ユーティリティーを使用して、バイナリログファイルの内容を表示できます。これはリカバリ操作のためにログ内のステートメントを再処理するときに役立ちます。たとえば、次のようにしてバイナリログから MySQL Server を更新できます。

shell> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog は、レプリケーションスレーブのリレーログファイルの内容を表示するためにも使用できます。これは、これらがバイナリログファイルと同じ形式を使用して書き込まれるためです。mysqlbinlog ユーティリティーとその使用方法についての詳細は、セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。バイナリログおよびリカバリ操作の詳細については、セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください。

バイナリロギングは、ステートメントまたはトランザクションの完了後すぐに行われますが、すべてのロックがリリースされるかコミットが実行されるよりも前になります。これにより、ログがコミット順に記録されることが保証されます。

非トランザクションテーブルへの更新は、実行後すぐにバイナリログに格納されます。

コミットなしのトランザクション内では、InnoDB テーブルなどのトランザクションテーブルを変更するすべての更新 (UPDATE、DELETE、INSERT) は、サーバーによって COMMIT ステートメントが受け取られるまでキャッシュされます。その時点で、COMMIT が実行される前に mysqld はトランザクション全体をバイナリログに書き込みます。

非トランザクションテーブルへの変更はロールバックできません。ロールバックされるトランザクションに非トランザクションテーブルへの変更が含まれている場合は、非トランザクションテーブルへの変更が確実にレプリケーションされるようにするために、最後に ROLLBACK ステートメントを使用してトランザクション全体がログに記録されます。

トランザクションを処理するスレッドが開始すると、スレッドは binlog_cache_size のバッファーをバッファーステートメントに割り当てます。ステートメントがこれより大きい場合、スレッドはトランザクションを格納する一時ファイルを開きます。スレッドが終了すると、一時ファイルは削除されます。

Binlog_cache_use ステータス変数は、ステートメントを格納するために、このバッファー (および場合によっては一時ファイル) を使用したトランザクションの数を表示します。Binlog_cache_disk_use ステータス変数は、それらのトランザクションのうち、実際に一時ファイルを使用する必要があったものの数を表示します。これらの 2 つの変数は、一時ファイルの使用を避けるために十分な値になるよう binlog_cache_size を調整するために使用することができます。

max_binlog_cache_size システム変数 (デフォルトは最大値の 4G バイト) を使用して、複数ステートメントのトランザクションをキャッシュするために使用する合計サイズを制限することができます。トランザクションがこのバイト数より大きくなると、失敗してロールバックします。最小値は 4096 です。

バイナリログおよび行ベースのロギングを使用している場合、並列挿入は CREATE ... SELECT または INSERT ... SELECT ステートメントの一般的な挿入に変換されます。これは、バックアップ操作中にログを適用することでテーブルの正確なコピーを確実に再作成できるようにするために行われます。ステートメントベースのロギングを使用している場合、元のステートメントがログに書き込まれます。

バイナリログ形式には、バックアップからのリカバリに影響する可能性があるいくつかの既知の制約があります。セクション17.4.1「レプリケーションの機能と問題」を参照してください。

ストアドプログラムのバイナリロギングは、セクション20.7「ストアドプログラムのバイナリロギング」で説明しているように行われます。

MySQL 5.6 のバイナリログ形式は、レプリケーションの機能拡張により以前のバージョンの MySQL とは異なることに注意してください。セクション17.4.2「MySQL バージョン間のレプリケーション互換性」を参照してください。

バイナリログファイルとバイナリログインデックスファイルへの書き込みは、MyISAM テーブルへの書き込みと同じ方法で処理されます。セクションB.5.4.3「MySQL が満杯のディスクを処理する方法」を参照してください。

デフォルトでは、バイナリログは毎回の書き込みごとにディスクと同期されるわけではありません。したがって、(MySQL Server だけでなく) オペレーティングシステムまたはマシンがクラッシュした場合、バイナリログの最後のステートメントが失われる可能性があります。これを防ぐには、sync_binlog システム変数を使用して、N 件のコミットグループが済むごとにバイナリログをディスクに同期させます。セクション5.1.4「サーバーシステム変数」を参照してください。もっとも安全な sync_binlog の値は 1 ですが、もっとも遅い値でもあります。sync_binlog が 1 に設定されたとしても、クラッシュ時にテーブルの内容とバイナリログの内容の間に不一致が生じる可能性があります。

たとえば、InnoDB テーブルを使用していて MySQL Server が COMMIT ステートメントを処理した場合、MySQL Server は作成済みの多くのトランザクションをバイナリログに順番に書き込み、バイナリログを同期させ、次にこのトランザクションを InnoDB にコミットします。これらの 2 つの操作を処理している間にサーバーがクラッシュすると、このトランザクションは再起動時に InnoDB によってロールバックされますが、バイナリログにはまだ存在します。このような問題は、--innodb_support_xa がデフォルトの 1 に設定されていたと仮定すれば解決されます。このオプションは InnoDB 内の XA トランザクションのサポートに関係しますが、このオプションは、バイナリログおよび InnoDB データファイルが同期されていることも保証します。このオプションによって、より高い安全性が提供されるようにするために、MySQL Server はトランザクションをコミットする前に、バイナリログおよび InnoDB ログをディスクに同期するようにも構成されるようにします。InnoDB ログはデフォルトで同期されるため、バイナリログを同期するために sync_binlog=1 を使用することができます。このオプションの影響は、クラッシュ後の再起動時にトランザクションのロールバックを行なったあと、MySQL Server はロールバック済みの InnoDB トランザクションをバイナリログから削除する、ということになります。これにより、バイナリログは InnoDB テーブルの正確なデータを反映し、したがって、スレーブはロールバック済みのステートメントを受け取らないため、マスターとの同期状態が維持されます。

バイナリログが、必要な長さよりも短いということを、MySQL Server がクラッシュリカバリ中に検出した場合、正常にコミットされた InnoDB トランザクションが、少なくとも 1 つバイナリログから欠落していることを示しています。これは sync_binlog=1 の場合は発生するはずがなく、ディスクまたはファイルシステムは、リクエストされた場合は (されない場合もあります) 実際の同期を実行するため、サーバーは「The binary log file_name is shorter than its expected size」というエラーメッセージを出力します。この場合、このバイナリログは正しくないため、マスターのデータのフレッシュスナップショットからレプリケーションを再起動するようにしてください。

次のシステム変数のセッション値はバイナリログに書き込まれ、バイナリログを構文解析するときにレプリケーションスレーブによって受け付けられます。

• sql_mode (NO_DIR_IN_CREATE モードがレプリケーションされない場合を除きます。セクション17.4.1.34「レプリケーションと変数」を参照してください)

• foreign_key_checks

• unique_checks

• character_set_client

• collation_connection

• collation_database

• collation_server

• sql_auto_is_null