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

MIXED のロギング形式で実行すると、サーバーは次の条件のときにステートメントベースのロギングから行ベースのロギングに自動的に切り替わります。

• 関数に UUID() が含まれているとき。

• AUTO_INCREMENT カラムを含む 1 つ以上のテーブルが更新され、トリガーまたはストアドファンクションが呼び出されたとき。ほかのすべての安全でないステートメントのように、binlog_format = STATEMENT の場合にこれによって警告が生成されます。

  詳細については、セクション17.4.1.1「レプリケーションと AUTO_INCREMENT」を参照してください。

• ビューの本体が行ベースのレプリケーションを必要とするときに、ビューを作成するステートメントもそれを使用するとき。たとえば、ビューを作成するステートメントが UUID() 関数を使用するときに発生します。

• UDF の呼び出しが含まれるとき。

• 非トランザクションテーブルに対して INSERT DELAYED が実行されるとき。

• ステートメントが行ごとにログに記録され、ステートメントを実行したセッションがいずれかの一時テーブルを持つ場合、そのセッションによって使用中のすべての一時テーブルが削除されるまでは、後続のすべてのステートメントで行ごとのロギングが使用されます (一時テーブルにアクセスするステートメントを除きます)。

  これは、いずれかの一時テーブルが実際にログに記録されているかどうかにかかわらず当てはまります。

  行ベースの形式を使用して一時テーブルをログに記録することはできないため、行ベースのロギングが使用されると、そのテーブルを使用する後続のすべてのステートメントは安全でなくなります。セッションが一時テーブルを保持しなくなるまで、サーバーはセッション中に実行されるすべてのステートメントを扱うことによって、この状況を安全でないものとして推定します。

• FOUND_ROWS() または ROW_COUNT() が使用されるとき。(Bug #12092、Bug #30244)

• USER()、CURRENT_USER()、または CURRENT_USER が使用されるとき。(Bug #28086)

• ステートメントが 1 つ以上のシステム変数を参照するとき。(Bug #31168)

  例外  次のシステム変数がセッションスコープ (のみ) で使用された場合、ロギング形式の切り替えは発生しません。

  • auto_increment_increment

  • auto_increment_offset

  • character_set_client

  • character_set_connection

  • character_set_database

  • character_set_server

  • collation_connection

  • collation_database

  • collation_server

  • foreign_key_checks

  • identity

  • last_insert_id

  • lc_time_names

  • pseudo_thread_id

  • sql_auto_is_null

  • time_zone

  • timestamp

  • unique_checks

  システム変数スコープを決定することについては、セクション5.1.5「システム変数の使用」を参照してください。

  レプリケーションが sql_mode を処理する方法については、セクション17.4.1.34「レプリケーションと変数」を参照してください。

• 関係するテーブルの 1 つが mysql データベース内のログテーブルのとき。

• LOAD_FILE() 関数が使用されるとき。(Bug #39701)

注記

行ベースのロギングを使用して記述されるべきステートメントをステートメントベースのロギングを使用して実行しようとすると、警告が生成されます。警告は、クライアント (SHOW WARNINGS の出力内) および mysqld エラーログの両方に表示されます。そのようなステートメントが実行されるごとに警告が SHOW WARNINGS テーブルに追加されます。ただし、ログがいっぱいになるのを防ぐために、各クライアントセッションについて警告を生成した最初のステートメントのみがエラーログに書き込まれます。

前述の判断のほかに、テーブル内の情報が更新されるときに使用されるロギング形式が、個々のエンジンによって決定される場合もあります。個々のエンジンのロギング機能は、次のように定義することができます。

• エンジンが行ベースのロギングをサポートする場合、そのエンジンは行ロギング対応といいます。

• エンジンがステートメントベースのロギングをサポートする場合、そのエンジンはステートメントロギング対応といいます。

ある特定のストレージエンジンは、いずれかまたは両方のロギング形式をサポートできます。次の表に、各エンジンによってサポートされる形式を示します。

ストレージエンジン	行ロギングのサポート	ステートメントロギングのサポート
ARCHIVE	はい	はい
BLACKHOLE	はい	はい
CSV	はい	はい
EXAMPLE	はい	いいえ
FEDERATED	はい	はい
HEAP	はい	はい
InnoDB	はい	トランザクション分離レベルが REPEATABLE READ または SERIALIZABLE の場合は「はい」、それ以外の場合は「いいえ」。
MyISAM	はい	はい
MERGE	はい	はい
NDB	はい	いいえ

MySQL 5.6 では、ステートメントがログに記録されるかどうか、および使用されるロギングモードは、ステートメントのタイプ (安全、安全でない、またはバイナリインジェクション)、バイナリロギング形式 (STATEMENT、ROW、または MIXED)、およびストレージエンジンのロギング機能 (ステートメント対応、行対応、両方、またはいずれでもない) に応じて決定されます。(バイナリインジェクションとは、ROW 形式を使用してログに記録する必要がある変更のロギングのことをいいます。)

ステートメントがログに記録されるときに警告を出す場合と出さない場合があります。失敗したステートメントはログに記録されませんが、ログにエラーが生成されます。これを次の決定表に示します。ここで、SLC は「ステートメントロギング対応」を示し、RLC は「行ロギング対応」を指します。

条件				アクション
型	binlog_format	SLC	RLC	エラーまたは警告	ロギング形式
*	*	いいえ	いいえ	Error: Cannot execute statement: 行ロギングにもステートメントロギングにも対応していないエンジンが少なくとも 1 つあるためバイナリロギングは不可能です。	-
安全	STATEMENT	はい	いいえ	-	STATEMENT
安全	MIXED	はい	いいえ	-	STATEMENT
安全	ROW	はい	いいえ	Error: Cannot execute statement: BINLOG_FORMAT = ROW であり、少なくとも 1 つのテーブルが、行ベースのロギングに対応しないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
安全でない	STATEMENT	はい	いいえ	Warning: Unsafe statement binlogged in statement format: BINLOG_FORMAT = STATEMENTであるため。	STATEMENT
安全でない	MIXED	はい	いいえ	Error: Cannot execute statement: BINLOG_FORMAT = MIXED であっても、ストレージエンジンがステートメントベースのロギングに限定されている場合、安全でないステートメントのバイナリロギングは不可能です。	-
安全でない	ROW	はい	いいえ	Error: Cannot execute statement: BINLOG_FORMAT = ROW であり、少なくとも 1 つのテーブルが、行ベースのロギングに対応しないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
行インジェクション	STATEMENT	はい	いいえ	Error: Cannot execute row injection: 少なくとも 1 つのテーブルが、行ベースのロギングに対応していないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
行インジェクション	MIXED	はい	いいえ	Error: Cannot execute row injection: 少なくとも 1 つのテーブルが、行ベースのロギングに対応していないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
行インジェクション	ROW	はい	いいえ	Error: Cannot execute row injection: 少なくとも 1 つのテーブルが、行ベースのロギングに対応していないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
安全	STATEMENT	いいえ	はい	Error: Cannot execute statement: BINLOG_FORMAT = STATEMENT であり、少なくとも 1 つのテーブルが、ステートメントベースのロギングに対応しないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
安全	MIXED	いいえ	はい	-	ROW
安全	ROW	いいえ	はい	-	ROW
安全でない	STATEMENT	いいえ	はい	Error: Cannot execute statement: BINLOG_FORMAT = STATEMENT であり、少なくとも 1 つのテーブルが、ステートメントベースのロギングに対応しないストレージエンジンを使用しているため、バイナリロギングは不可能です。	-
安全でない	MIXED	いいえ	はい	-	ROW
安全でない	ROW	いいえ	はい	-	ROW
行インジェクション	STATEMENT	いいえ	はい	Error: Cannot execute row injection: BINLOG_FORMAT = STATEMENTのため、バイナリロギングは不可能です。	-
行インジェクション	MIXED	いいえ	はい	-	ROW
行インジェクション	ROW	いいえ	はい	-	ROW
安全	STATEMENT	はい	はい	-	STATEMENT
安全	MIXED	はい	はい	-	STATEMENT
安全	ROW	はい	はい	-	ROW
安全でない	STATEMENT	はい	はい	Warning: Unsafe statement binlogged in statement format: BINLOG_FORMAT = STATEMENTであるため。	STATEMENT
安全でない	MIXED	はい	はい	-	ROW
安全でない	ROW	はい	はい	-	ROW
行インジェクション	STATEMENT	はい	はい	Error: Cannot execute row injection: BINLOG_FORMAT = STATEMENTのため、バイナリロギングは不可能です。	-
行インジェクション	MIXED	はい	はい	-	ROW
行インジェクション	ROW	はい	はい	-	ROW

決定によって警告が生成される場合、標準の MySQL 警告が生成されます (警告は SHOW WARNINGS を使用して確認できます)。この情報は mysqld エラーログにも書き込まれます。ログがいっぱいになるのを防ぐために、エラーは各クライアント接続のエラー発生ごとに 1 つだけログに記録されます。ログメッセージには試行された SQL ステートメントが含められます。

スレーブサーバーが --log-warnings を有効にして起動された場合、スレーブは、スレーブのステータスに関する情報を提供するためのメッセージをエラーログに出力し、この情報には、スレーブがジョブを開始したときのバイナリログおよびリレーログの座標、別のリレーログに切り替える時期、切断後に再接続する時期などがあります。