MySQL 8.0 リファレンスマニュアル


MySQL 8.0 リファレンスマニュアル  /  ...  /  混合形式のバイナリロギング形式

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 はい いいえ

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

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


関連キーワード:  ロギング, ステートメント, バイナリ, 形式, ログ, エンジン, サーバー, 変数, ベース, テーブル