このページは機械翻訳したものです。

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

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

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

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

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

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

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

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

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

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

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

• ステートメントが 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.9「システム変数の使用」を参照してください。

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

以前のリリースでは、混合バイナリロギング形式が使用されていたときに、ステートメントが行ごとにログに記録され、ステートメントを実行したセッションに一時テーブルがある場合、そのセッションで使用されているすべての一時テーブルが削除されるまで、後続のすべてのステートメントは安全でないものとして扱われ、行ベース形式でログに記録されていました。 MySQL 8.0 の時点では、一時テーブルに対する操作は混合バイナリロギング形式で記録されず、セッション内に一時テーブルが存在しても、ステートメントごとに使用されるロギングモードには影響しません。

注記

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

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

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

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

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

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

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

ステートメントがログに記録されるときに警告を出す場合と出さない場合があります。失敗したステートメントはログに記録されませんが、ログにエラーが生成されます。 これを次のデシジョンテーブルに示します。 Type、binlog_format、SLC および RLC のカラムは条件の概要を示し、エラー / 警告およびログイン名のカラムは対応するアクションを表します。 SLC 「「statement-logging 対応」」を表し、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_error_verbosity がある場合、レプリカはメッセージをエラーログに出力して、ジョブを開始するバイナリログとリレーログの座標、別のリレーログへの切替え時、切断後の再接続時、ステートメントベースのロギングに安全でないステートメントなどのステータスに関する情報を提供します。