Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


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

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

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_formatSLCRLCエラーまたは警告ロギング形式
**いいえいいえ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 がある場合、レプリカはメッセージをエラーログに出力して、ジョブを開始するバイナリログとリレーログの座標、別のリレーログへの切替え時、切断後の再接続時、ステートメントベースのロギングに安全でないステートメントなどのステータスに関する情報を提供します。