バイナリログは、以前の更新ログの代わりになるものです。更新ログは MySQL 5.0 でなくなります。バイナリログには、更新ログで利用可能だった情報がすべて、より効率的かつトランザクションセーフな方法で含まれます。

バイナリログは以前の更新ログと同様、データを実際に更新するステートメントだけを記録します。UPDATE または DELETE の WHERE 指定でレコードが見つからなかった場合、そのステートメントはログに書き込まれません。カラムの値を、すでにある同じ値で更新した UPDATE ステートメントもスキップされます。

バイナリログには、バックアップ後の更新がすべて記録されます。バイナリログの主な目的は、リストア時に、データベースに対して可能な限りバックアップ後の更新を実行できるようにすることです。

バイナリログは、マスタからスレーブにレプリケーションを行うときにも使用します。 See 項4.11. 「MySQL のレプリケーション」。

バイナリログには、データベースを更新した各クエリにかかった時間の情報も含まれます。データを変更しなかったクエリは含まれません。問題のあるクエリを見つけるなどの目的ですべてのクエリを記録したい場合には、一般クエリログを使用してください。 See 項4.10.2. 「一般クエリログ」。

mysqld を --log-bin[=file_name] オプションで起動すると、データを更新したすべての SQL コマンドがログファイルに記録されます。ファイル名を指定しなければ、ホストマシンの名前に -bin を付けたものがデフォルト名になります。ファイル名を指定し、パスを指定していない場合には、ファイルはデータディレクトリに作成されます。

--log-bin=filename.extension で拡張子を指定した場合、拡張子は削除されます。

mysqld は、バイナリログファイル名に数字の拡張子を追加します。この番号は、mysqladmin refresh、mysqladmin flush-logs、および FLUSH LOGS ステートメントが実行されるたびに、またはサーバが再起動するたびにインクリメントされます。バイナリログのサイズが max_binlog_size に達すると、新しいバイナリログが自動的に作成されます。注意: トランザクションを使用している場合、トランザクションは 1 つのまとまりでバイナリログに書き込まれるため、複数のバイナリログに分割されることはありません。したがって、大きなトランザクションがある場合、バイナリログが max_binlog_size より大きくなる可能性があります。

すべてのバイナリログファイルを削除するには、RESET MASTER コマンド（see 項4.6.5. 「RESET 構文」）を使用します。一部のファイルを削除するには、PURGE MASTER LOGS（see 項4.11.7. 「マスタサーバを制御する SQL ステートメント」）を使用します。

mysqld で以下のオプションを使用し、何をバイナリログに記録するか制御できます（表の後の説明を必ず読んでください）。

クエリをバイナリログに書き込むかどうかの評価は、以下の順序で行われます。

したがって、たとえば binlog-do-db=sales だけで実行中のスレーブは、カレントデータベースが sales ではないクエリを一切バイナリログに書き込みません（つまり、binlog-do-db は ``他のデータベースを無視する'' ということにもなります）。

どのバイナリログファイルが使用されたかわかるように、mysqld はバイナリログインデックスファイルも作成します。このファイルに、使用されたバイナリログファイルすべての名前が含まれます。デフォルトでは、このファイルの名前はバイナリログファイル名に拡張子 '.index' を付けたものとなります。 バイナリログインデックスファイルの名前を変更するには、--log-bin-index=[filename] オプションを使用します。 mysqld の実行中は、このファイルを手動で編集しないでください。mysqld が混乱する原因となります。

レプリケーションを使用している場合、スレーブが必要としている間は、古いバイナリログファイルを削除しないでください。 たとえば、mysqladmin flush-logs を毎日実行する場合、3 日たったログをすべて削除するようにします。これらのログは手動で削除することもできますが、バイナリログインデックスファイルも安全に更新できる PURGE MASTER LOGS（see 項4.11.7. 「マスタサーバを制御する SQL ステートメント」）を使用して削除することを推奨します。このコマンドは、MySQL 4.1 から日付引数を指定できるようになっています。

SUPER 権限での接続では、SET SQL_LOG_BIN=0 を使用して、クエリのバイナリログを無効にできます。 See 項4.11.7. 「マスタサーバを制御する SQL ステートメント」。

バイナリログファイルを調べるには、mysqlbinlog ユーティリティを使用します。 たとえば、以下のようにバイナリログから MySQL サーバを更新することができます。

shell> mysqlbinlog log-file | mysql -h server_name

mysqlbinlog ユーティリティおよびその使用法に関する詳細については、項4.9.5. 「mysqlbinlog（バイナリログからクエリを実行する）」 を参照してください。

BEGIN [WORK] または SET AUTOCOMMIT=0 を使用している場合は、以前の更新ログではなく MySQL バイナリログをバックアップ用に使用してください。更新ログは MySQL 5.0 でなくなります。

バイナリログの書き込みは、クエリが完了した直後でロックの解除前に、またはコミットの前に行われます。このため、ログは実行順序どおりに書き込まれます。

非トランザクションテーブルの更新は実行直後にバイナリログに保存されます。BDB テーブルや InnoDB テーブルなどのトランザクションテーブルでは、テーブルを変更するすべての更新（UPDATE、DELETE、または INSERT）は、COMMIT コマンドがサーバに送信されるまでキャッシュされます。mysqld は、COMMIT が実行される前にトランザクション全体をバイナリログに書き込みます。 すべてのスレッドが、最初に、クエリをバッファする binlog_cache_size のバッファを割り当てます。クエリがこれより大きい場合、スレッドはテンポラリファイルを開いてトランザクションを保存します。スレッドが終了するとテンポラリファイルは削除されます。

max_binlog_cache_size（デフォルトは 4G）を使用して、複数クエリトランザクションのキャッシュに使用するトータルサイズを制限できます。トランザクションがこれより大きい場合、エラーとなってロールバックします。

更新ログまたはバイナリログを使用している場合に、CREATE ... SELECT または INSERT ... SELECT を使用すると、同時挿入が通常の挿入に変換されます。 これは、バックアップにログを適用したときに、テーブルの正確なコピーを作成するための措置です。