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

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

• STATEMENT の場合、ロギングはステートメントに基づきます。

• ROW の場合、ロギングは行に基づきます。

• MIXED の場合、ロギングは混合形式を使用します。

MySQL 5.6 では、デフォルトのバイナリロギング形式は STATEMENT です。

ロギング形式は実行時でも変更できます。すべてのクライアントについてグローバルに形式を指定するには、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';

注記

それぞれの MySQL Server は、サーバー独自のバイナリロギング形式のみを設定できます (binlog_format がグローバルスコープまたはセッションスコープのいずれで設定される場合にも当てはまります)。これは、レプリケーションマスターのロギング形式を変更しても、スレーブがそのロギング形式を一致するように変更するわけではないことを意味しています。(STATEMENT モードを使用中の場合、binlog_format システム変数はレプリケーションされず、MIXED または ROW ロギングモードを使用中の場合、レプリケーションされますが、スレーブによって無視されます。)レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上でそれを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くことがあります。

グローバル値またはセッション値 binlog_format を変更するには、SUPER 権限が必要です。

ロギング形式の手動による切り替えのほかに、スレーブサーバーが自動的にその形式を変更する場合もあります。これは、サーバーが STATEMENT または MIXED のいずれかの形式で実行していて、ROW ロギング形式で書き込まれたイベントをバイナリログ内で検出した場合に発生します。この場合、スレーブはそのイベントについて行ベースのレプリケーションに一時的に切り替わり、そのあとで以前の元の形式に切り替わります。

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

• 多くの小さい変更をデータベースに行うセッションでは、行ベースのロギングを使用した方がよい場合があります。

• WHERE 句で多くの行と一致する更新を実行するセッションでは、多くの行よりも 2、3 件のステートメントをログに記録する方が効率的であるため、ステートメントベースのロギングを使用した方がよい場合があります。

• 一部のステートメントでは、マスター上で多くの実行時間を必要とするが、変更される行がわずか数行ということがあります。したがって、行ベースのロギングを使用してそれらの行をレプリケーションする方が有益なことがあります。

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

• ストアドファンクションまたはトリガーから実行する場合

• NDB ストレージエンジンが有効な場合

• セッションが現在行ベースのレプリケーションモードで、一時テーブルが開いている場合

これらのいずれかの場合に形式を切り替えようとすると、結果はエラーになります。

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

一時テーブルが存在する場合にレプリケーション形式を実行時に切り替えることは推奨されません。これは、一時テーブルはステートメントベースのレプリケーションを使用中の場合にのみログに記録され、行ベースのレプリケーションではこれらはログに記録されないためです。混合形式のレプリケーションでは、一時テーブルは通常はログに記録されます。ユーザー定義関数 (UDF) および UUID() 関数については例外が発生します。

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

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

警告

レプリケーション用にステートメントベースのロギングを使用している場合、ステートメントの設計方法が、データ変更が非決定的である (つまりクエリーオプティマイザの意向に委ねられるようになっている) ときに、マスターとスレーブのデータが異なることがあります。一般的に、これはレプリケーションの領域外であっても適切なやり方ではありません。この問題についての詳細な説明は、セクションB.5.8「MySQL の既知の問題」を参照してください。

レプリケーションスレーブによって保持されるログについては、セクション17.2.2「レプリケーションリレーおよびステータスログ」を参照してください。