MySQL Server を --binlog-format=type で起動することによって、バイナリロギング形式を明示的に選択することができます。 type については次の値がサポートされます。

ロギング形式は実行時に切り替えることもできますが、このセクションの後半で説明するように、これを実行できない状況が多数あることに注意してください。 binlog_format システム変数のグローバル値を設定して、変更後に接続するクライアントの形式を指定します:

mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

個別クライアントは binlog_format のセッション値を設定することによって、クライアント自身のステートメントについてのロギング形式を制御することができます。

mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';

グローバル binlog_format 値を変更するには、グローバルシステム変数を設定するのに十分な権限が必要です。 セッションの binlog_format 値を変更するには、制限付きセッションシステム変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

クライアントがセッションごとにバイナリロギングを設定することには、いくつかの理由があります。

レプリケーション形式を実行時に切り替えることができない例外もあります。

これらのいずれかの場合 (または現在のレプリケーション形式を設定しようとする場合) にレプリケーション形式を切り替えようとすると、エラーになります。 ただし、PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format) を使用してレプリケーション形式をいつでも変更できます。これは、このアクションによってランタイムグローバルシステム変数の値が変更されず、サーバーの再起動後にのみ有効になるためです。

一時テーブルが存在する場合、実行時にレプリケーション形式を切り替えることはお勧めしません。一時テーブルはステートメントベースレプリケーションの使用時にのみログに記録されますが、行ベースレプリケーションと混在レプリケーションではログに記録されないためです。

レプリケーションの進行中にレプリケーション形式を切り替えると、問題が発生する可能性もあります。 それぞれの MySQL Server は、サーバー独自のバイナリロギング形式のみを設定できます (binlog_format がグローバルスコープまたはセッションスコープのいずれで設定される場合にも当てはまります)。 つまり、レプリケーションソースサーバーでロギング形式を変更しても、レプリカはそのロギング形式を一致させることはできません。 STATEMENT モードを使用する場合、binlog_format システム変数はレプリケートされません。 MIXED または ROW ロギングモードを使用している場合、レプリケートされますが、レプリカでは無視されます。

レプリカは、ROW ロギング形式で受信したバイナリログエントリを、独自のバイナリログで使用するために STATEMENT 形式に変換できません。 そのため、ソースの場合、レプリカは ROW または MIXED 形式を使用する必要があります。 レプリケーションが STATEMENT 形式のレプリカに進行中にソースのバイナリロギング形式を STATEMENT から ROW または MIXED に変更すると、レプリケーションが「行イベント実行中のエラー: 'ステートメントを実行できません: ステートメントは行形式で BINLOG_FORMAT=STATEMENT であるため、バイナリログに書き込めません。'」などのエラーで失敗することがあります ソースがまだ MIXED または ROW 形式を使用している場合にレプリカのバイナリロギング形式を STATEMENT 形式に変更すると、同じタイプのレプリケーションも失敗します。 フォーマットを安全に変更するには、レプリケーションを停止し、ソースとレプリカの両方で同じ変更が行われていることを確認する必要があります。

InnoDB テーブルを使用中で、トランザクション分離レベルが READ COMMITTED または READ UNCOMMITTED の場合、行ベースのロギングのみを使用することができます。 ロギング形式を STATEMENT に変更することは可能ですが、InnoDB は挿入を実行できないため、実行時にこれを行うと、非常に速くエラーが発生します。

バイナリログ形式を ROW に設定すると、多くの変更は行ベースの形式を使用してバイナリログに書き込まれます。 しかし、一部の変更ではステートメントベース形式が使用されます。 たとえば、CREATE TABLE、ALTER TABLE、DROP TABLE などのすべての DDL (データ定義言語) ステートメントがこれに該当します。

行ベースのバイナリロギングを使用する場合、binlog_row_event_max_size システム変数とそれに対応する起動オプション --binlog-row-event-max-size は、行イベントの最大サイズに弱い制限を設定します。 デフォルト値は 8192 バイトで、値はサーバーの起動時にのみ変更できます。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。

--binlog-row-event-max-size オプションは、行ベースのレプリケーションが可能なサーバーで使用できます。 行は、このオプションの値を越えないバイト単位のサイズを持つチャンクとして、バイナリログに格納されます。 この値は 256 の倍数である必要があります。 デフォルト値は 8192 です。