--binlog-row-event-max-size=N

行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。

--log-bin[=base_name]

バイナリログファイルに使用するベース名を指定します。 バイナリロギングが有効になっている場合、サーバーは、データを変更するすべてのステートメントをバイナリログに記録します。バイナリログは、バックアップとレプリケーションに使用されます。 バイナリログは、ベース名と数値拡張子を持つ一連のファイルです。 --log-bin オプションの値は、ログ順序のベース名です。 サーバーは、ベース名に数値の接尾辞を追加して、バイナリログファイルを順番に作成します。

--log-bin オプションを指定しない場合、MySQL はバイナリログファイルのデフォルトのベース名として binlog を使用します。 以前のリリースとの互換性のために、文字列なしまたは空の文字列を指定して --log-bin オプションを指定した場合、ベース名はホストマシンの名前を使用して host_name-bin にデフォルト設定されます。

バイナリログファイルのデフォルトの場所はデータディレクトリです。 ベース名に先頭の絶対パス名を追加して別のディレクトリを指定することで、--log-bin オプションを使用して別の場所を指定できます。 サーバーは、使用されたバイナリログファイルを追跡するバイナリログインデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれているかどうかを確認します。 その場合、パスの相対部分は、--log-bin オプションを使用して設定された絶対パスに置き換えられます。 バイナリログインデックスファイルに記録された絶対パスは変更されません。このような場合は、新しいパスを使用できるようにインデックスファイルを手動で編集する必要があります。 バイナリログファイルのベース名と指定されたパスは、log_bin_basename システム変数として使用できます。

以前の MySQL バージョンでは、バイナリロギングはデフォルトで無効になっており、--log-bin オプションを指定した場合は有効になっていました。 MySQL 8.0 からは、--log-bin オプションを指定するかどうかにかかわらず、バイナリロギングはデフォルトで有効になっています。 例外は、バイナリロギングがデフォルトで無効になっている場合に、mysqld を使用して --initialize または --initialize-insecure オプションを指定してデータディレクトリを手動で呼び出すことによって、データディレクトリを初期化する場合です。 この場合、--log-bin オプションを指定することでバイナリロギングを有効にできます。 バイナリロギングが有効になっている場合、サーバー上のバイナリロギングのステータスを示す log_bin システム変数は ON に設定されます。

バイナリロギングを無効にするには、起動時に --skip-log-bin または --disable-log-bin オプションを指定できます。 これらのオプションのいずれかが指定され、--log-bin も指定されている場合は、後で指定するオプションが優先されます。 バイナリロギングが無効になっている場合、log_bin システム変数は OFF に設定されます。

GTID がサーバーで使用されているときに、異常シャットダウン後にサーバーを再起動するときにバイナリロギングを無効にすると、GTID の一部が失われ、レプリケーションが失敗する可能性があります。 通常のシャットダウンでは、現在のバイナリログファイルから GTID のセットが mysql.gtid_executed テーブルに保存されます。 これが発生しなかった異常なシャットダウンのあと、バイナリロギングがまだ有効になっている場合は、回復中に GTID がバイナリログファイルからテーブルに追加されます。 サーバーの再起動に対してバイナリロギングが無効になっている場合、サーバーはバイナリログファイルにアクセスして GTID を回復できないため、レプリケーションを開始できません。 バイナリロギングは、通常のシャットダウン後に安全に無効にできます。

--log-slave-updates および --slave-preserve-commit-order オプションにはバイナリロギングが必要です。 バイナリロギングを無効にする場合は、これらのオプションを省略するか、--log-slave-updates=OFF および --skip-slave-preserve-commit-order を指定します。 --skip-log-bin または --disable-log-bin が指定されている場合、MySQL はこれらのオプションをデフォルトで無効にします。 --log-slave-updates または --slave-preserve-commit-order を --skip-log-bin または --disable-log-bin とともに指定すると、警告またはエラーメッセージが発行されます。

MySQL 5.7 では、バイナリロギングが有効になっているときにサーバー ID を指定する必要がありました。そうしないと、サーバーが起動しません。 MySQL 8.0 では、server_id システム変数はデフォルトで 1 に設定されています。 バイナリロギングが有効になっている場合、このデフォルトのサーバー ID を使用してサーバーを起動できるようになりましたが、server_id システム変数を設定してサーバー ID を明示的に指定しないと、情報メッセージが発行されます。 レプリケーショントポロジで使用されるサーバーの場合、サーバーごとにゼロ以外の一意のサーバー ID を指定する必要があります。

バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。

--log-bin-index[=file_name]

バイナリログインデックスファイルの名前。バイナリログファイルの名前が含まれます。 デフォルトでは、--log-bin オプションと拡張子 .index を使用してバイナリログファイルに指定された値と同じ場所とベース名を持ちます。 --log-bin を指定しない場合、デフォルトのバイナリログインデックスファイル名は binlog.index です。 文字列または空の文字列を指定せずに --log-bin オプションを指定した場合、デフォルトのバイナリログインデックスファイル名は、ホストマシンの名前を使用して host_name-bin.index になります。

バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。

--binlog-do-db=db_name

このオプションは、--replicate-do-db がレプリケーションに影響するのと同様にバイナリロギングに影響します。

このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (--replicate-do-db の影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。 指定されたステートメントのログを記録するために使用される形式が、binlog_format の値で示される形式と必ずしも同じではないことに留意してください。 たとえば、CREATE TABLE や ALTER TABLE などの DDL ステートメントは、有効になっているロギング形式にかかわらず、常にステートメントとしてログが記録されるため、--binlog-do-db の次のステートメントベースルールはステートメントのログが記録されるかどうかの判断に常に適用されます。

ステートメントベースのロギング.  デフォルトデータベース (つまり、USE で選択されたもの) が db_name であるステートメントだけが、バイナリログに書き込まれます。 複数のデータベースを指定するには、このオプションを複数回 （データベースごとに 1 回） 使用します。ただし、このようにしても、別のデータベースが選択されているとき （またはデータベースが選択されていないとき） に、UPDATE some_db.some_table SET foo='bar' などのクロスデータベースステートメントのログは記録されません。

ステートメントベースロギングを使用するときに想定される、機能しない例: サーバーが --binlog-do-db=sales で起動され、次のステートメントを発行する場合、UPDATE ステートメントのログは記録されません。

USE prices;
UPDATE sales.january SET amount=amount+1000;

この「デフォルトデータベースをチェックするだけ」動作の主な理由は、ステートメントだけから複製すべきかどうかを知ることが難しいことです (たとえば、複数のデータベースをまたがって動作する複数テーブル DELETE ステートメントまたは複数テーブル UPDATE ステートメントを使用する場合)。 また、必要がない場合、すべてのデータベースではなくデフォルトデータベースだけをチェックする方が早いです。

もう 1 つのケースは自明ではないかもしれませんが、オプションを設定するときに指定されなかったけれども所定のデータベースが複製されます。 サーバーが --binlog-do-db=sales で起動される場合、--binlog-do-db の設定時に prices が含まれなかったけれども、次の UPDATE ステートメントのログが記録されます。

USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;

UPDATE ステートメントが発行されたときに sales がデフォルトデータベースであるため、UPDATE のログが記録されます。

行ベースのロギング.  ロギングはデータベース db_name に制限されます。 db_name に属するテーブルへの変更だけがログに記録されます。デフォルトデータベースはこれに影響しません。 サーバーが --binlog-do-db=sales で起動され、行ベースロギングが有効であると想定すると、次のステートメントが実行されます。

USE prices;
UPDATE sales.february SET amount=amount+100;

sales データベース内の february テーブルへの変更が、UPDATE ステートメントに従ってログに記録されます。これは USE ステートメントが発行されたかどうかにかかわらず発生します。 ただし、行ベースロギング形式および --binlog-do-db=sales を使用するときは、次の UPDATE によって行われた変更のログは記録されません。

USE prices;
UPDATE prices.march SET amount=amount-25;

USE prices ステートメントが USE sales に変更された場合でも、UPDATE ステートメントの結果は依然としてバイナリログに書き込まれません。

--binlog-do-db 処理でステートメントベースロギングと行ベースロギング間のもう 1 つの重要な違いは、複数のデータベースを参照するステートメントに関して発生します。 サーバーが --binlog-do-db=db1 で起動され、次のステートメントが実行されると想定します。

USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

ステートメントベースロギングを使用している場合、両方のテーブルへの更新がバイナリログに書き込まれます。 一方、行ベース形式を使用するときは、table1 への変更だけがログに記録されます。table2 は別のデータベース内にあり、UPDATE によって変更されません。 ここで、USE db1 ステートメントの代わりに、USE db4 ステートメントが使用されたものとします。

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

この場合、ステートメントベースロギングを使用するときに UPDATE ステートメントはバイナリログに書き込まれません。 一方、行ベースロギングを使用するときは、table1 への変更のログは記録されますが、table2 へはそうなりません。つまり、--binlog-do-db によって指定されたデータベース内のテーブルへの変更のみがログに記録され、デフォルトデータベースの選択はこの動作に影響しません。

--binlog-ignore-db=db_name

このオプションは、--replicate-ignore-db がレプリケーションに影響するように、バイナリロギングに影響します。

このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (--replicate-ignore-db の影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。 指定されたステートメントのログを記録するために使用される形式が、binlog_format の値で示される形式と必ずしも同じではないことに留意してください。 たとえば、CREATE TABLE や ALTER TABLE などの DDL ステートメントは、有効になっているロギング形式にかかわらず、常にステートメントとしてログが記録されるため、--binlog-ignore-db の次のステートメントベースルールはステートメントのログが記録されるかどうかの判断に常に適用されます。

ステートメントベースのロギング.  デフォルトデータベース (つまり、USE で選択されたもの) が db_name であるステートメントのログを記録しないようにサーバーに指示します。

デフォルトのデータベースがない場合、--binlog-ignore-db オプションは適用されず、このようなステートメントは常にログに記録されます。 (Bug #11829838、Bug #60188)

行ベース形式.  データベース db_name 内のテーブルへの更新のログを記録しないようにサーバーに指示します。 現在のデータベースは影響しません。

ステートメントベースロギングを使用するとき、次の例は予期するとおりに機能しません。 サーバーが --binlog-ignore-db=sales で起動され、次のステートメントを発行すると想定します。

USE prices;
UPDATE sales.january SET amount=amount+1000;

--binlog-ignore-db がデフォルトデータベース (USE ステートメントで決定) にのみ適用されるため、このような場合は UPDATE ステートメントのログが記録されます。 sales データベースがステートメントで明示的に指定されたため、ステートメントはフィルタされませんでした。 ただし、行ベースのロギングを使用している場合、UPDATE ステートメントの効果はバイナリログに書き込まれません。つまり、sales.january テーブルへの変更は記録されません。この場合、--binlog-ignore-db=sales は sales データベースのソースコピー内のテーブルに対して行われた all の変更をバイナリロギングのために無視します。

無視するデータベースを複数指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。 データベース名にはカンマを含めることができるため、カンマ区切りリストを指定すると、リストは単一のデータベースの名前として扱われます。

クロスデータベース更新を使用していて、それらの更新ログを記録したくない場合は、このオプションを使用しないでください。

--binlog-checksum={NONE|CRC32}

このオプションを有効にすると、ソースはバイナリログに書き込まれたイベントのチェックサムを書き込みます。 NONE に設定して無効にするか、チェックサムの生成に使用するアルゴリズムの名前を指定します。現在、CRC32 チェックサムのみがサポートされており、CRC32 がデフォルトです。 トランザクション内のこのオプションの設定は変更できません。

--max-binlog-dump-events=N

このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。

--sporadic-binlog-dump-fail

このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。

binlog_cache_size

トランザクション中にバイナリログに対する変更を保持するメモリーバッファーのサイズ。 (log_bin システム変数を ON に設定して) サーバーでバイナリロギングが有効になっている場合、サーバーがトランザクションストレージエンジンをサポートしていれば、クライアントごとにバイナリログキャッシュが割り当てられます。 トランザクションのデータがメモリーバッファ内の領域を超えた場合、余分なデータは一時ファイルに格納されます。 バイナリログの暗号化がサーバーでアクティブな場合、メモリーバッファは暗号化されませんが、バイナリログキャッシュの保持に使用される一時ファイルは (MySQL 8.0.17 から) 暗号化されます。 各トランザクションがコミットされると、メモリーバッファをクリアし、一時ファイル (使用されている場合) を切り捨てることで、バイナリログキャッシュがリセットされます。

大規模なトランザクションを頻繁に使用する場合は、一時ファイルへの書込みを削減または排除することで、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。 Binlog_cache_use および Binlog_cache_disk_use ステータス変数は、この変数のサイズを調整するために役立つことがあります。 セクション5.4.4「バイナリログ」を参照してください。

binlog_cache_size はトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュのサイズは binlog_stmt_cache_size システム変数によって管理されます。

binlog_checksum

この変数を有効にすると、ソースは各イベントのチェックサムをバイナリログに書き込みます。binlog_checksum は、NONE (チェックサムを無効にする) および CRC32 の値をサポートしています。 デフォルトは CRC32 です。 binlog_checksum が無効 (値 NONE) のときは、サーバーは各イベントのイベント長 （チェックサムではなく） を書き込んでチェックすることで、すべてそろったイベントのみをバイナリログに書き込んでいることを検証します。

ソースでこの変数をレプリカで認識されない値に設定すると、レプリカは独自の binlog_checksum 値を NONE に設定し、エラーでレプリケーションを停止します。 古いレプリカとの下位互換性に問題がある場合は、値を明示的に NONE に設定できます。

MySQL 8.0.20 まで、グループレプリケーションはチェックサムを使用できず、バイナリログでのチェックサムの存在をサポートしないため、サーバーインスタンスがグループメンバーになるように構成するときに binlog_checksum=NONE を設定する必要があります。 MySQL 8.0.21 からは、グループレプリケーションでチェックサムがサポートされるため、グループメンバーはデフォルト設定を使用できます。

チェックサムはバイナリログファイル全体に対して書き込まれる必要があり、バイナリログの一部に対してのみ書き込まれないため、binlog_checksum の値を変更するとバイナリログがローテーションされます。 トランザクション内の binlog_checksum の値は変更できません。

binlog_transaction_compression システム変数を使用してバイナリログのトランザクション圧縮が有効になっている場合、圧縮されたトランザクションペイロード内の個々のイベントのチェックサムは書き込まれません。 代わりに、GTID イベントに対してチェックサムが書き込まれ、圧縮された Transaction_payload_event に対してチェックサムが書き込まれます。

binlog_direct_non_transactional_updates

同時実行性の問題のため、トランザクションにトランザクションテーブルと非トランザクションテーブルの両方に対する更新が含まれる場合、レプリカに一貫性がなくなる可能性があります。 MySQL は、非トランザクションステートメントをトランザクションキャッシュに書き込むことで （コミット時にフラッシュされる）、これらのステートメント間の因果関係を維持しようとします。 ただし、トランザクションに代わって非トランザクションテーブルに行われた変更がほかの接続にただちに可視になるときに、問題が起こります (これらの変更がただちにバイナリログに書き込まれない場合があるため)。

binlog_direct_non_transactional_updates 変数は、この問題に対する 1 つの可能な回避策を提供します。 デフォルトでは、この変数は無効です。 binlog_direct_non_transactional_updates を有効にすることで、非トランザクションテーブルへの更新が、トランザクションキャッシュではなく直接バイナリログに書き込まれます。

MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

binlog_direct_non_transactional_updates は、ステートメントベースバイナリロギング形式を使用して複製されるステートメントにのみ機能します。つまり、binlog_format の値が STATEMENT のとき、または binlog_format が MIXED で、与えられたステートメントがステートメントベース形式を使用して複製されているときにのみ機能します。 バイナリログ形式が ROW のとき、または binlog_format が MIXED に設定され、与えられたステートメントが行ベース形式で複製されるときは、この変数は効果がありません。

バイナリログ形式が ROW または MIXED の場合、この変数は無効です。

binlog_encryption

このサーバー上のバイナリログファイルおよびリレーログファイルの暗号化を有効にします。 OFF がデフォルトです。 ON は、バイナリログファイルおよびリレーログファイルの暗号化をオンに設定します。 暗号化を有効にするためにバイナリロギングをサーバー上で有効にする必要はないため、バイナリログのないレプリカ上のリレーログファイルを暗号化できます。 暗号化を使用するには、MySQL Server 鍵リングサービスを提供するように鍵リングプラグインをインストールして構成する必要があります。 これを行う手順は、セクション6.4.4「MySQL キーリング」 を参照してください。 サポートされている任意のキーリングプラグインを使用して、バイナリログ暗号化鍵を格納できます。

バイナリログ暗号化を有効にしてサーバーをはじめて起動すると、バイナリログとリレーログが初期化される前に新しいバイナリログ暗号化鍵が生成されます。 このキーは、各バイナリログファイル (サーバーでバイナリロギングが有効になっている場合) およびリレーログファイル (サーバーにレプリケーションチャネルがある場合) のファイルパスワードを暗号化するために使用され、ファイルパスワードから生成された以降の鍵を使用してファイル内のデータが暗号化されます。 リレーログファイルは、グループレプリケーションアプライヤチャネルや暗号化のアクティブ化後に作成される新しいチャネルなど、すべてのチャネルに対して暗号化されます。 バイナリログインデックスファイルとリレーログインデックスファイルは暗号化されません。

サーバーの実行中に暗号化をアクティブ化すると、その時点で新しいバイナリログ暗号化鍵が生成されます。 例外は、以前にサーバー上で暗号化がアクティブであり、その後無効になっていた場合です。その場合、以前に使用されていたバイナリログ暗号化鍵が再度使用されます。 バイナリログファイルとリレーログファイルはただちにローテーションされ、新しいファイルとそれ以降のすべてのバイナリログファイルおよびリレーログファイルのファイルパスワードは、このバイナリログ暗号化鍵を使用して暗号化されます。 既存のバイナリログファイルとリレーログファイルがサーバー上にまだ存在する場合、それらは自動的に暗号化されませんが、不要になった場合はパージできます。

binlog_encryption システム変数を OFF に変更して暗号化を非アクティブにすると、バイナリログファイルとリレーログファイルはただちにローテーションされ、それ以降のすべてのロギングは暗号化されません。 以前に暗号化されたファイルは自動的に復号化されませんが、サーバーはそれらを読み取ることができます。 サーバーの実行中に暗号化をアクティブ化または非アクティブ化するには、BINLOG_ENCRYPTION_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。 グループレプリケーションアプライヤチャネルはリレーログローテーションリクエストに含まれないため、これらのチャネルの暗号化されていないロギングは、ログが通常の使用でローテーションされるまで開始されません。

バイナリログファイルとリレーログファイルの暗号化の詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。

binlog_error_action

バイナリログへの書き込み、フラッシュ、同期ができないなどのエラーがサーバーで発生した場合に何が起こるかを制御します。これにより、ソースバイナリログが矛盾し、レプリカが同期を失う可能性があります。

この変数のデフォルトは ABORT_SERVER で、バイナリログでこのようなエラーが発生するたびに、サーバーはロギングを停止してシャットダウンします。 再起動時に、予期しないサーバーが停止した場合と同様にリカバリが続行されます (セクション17.4.2「レプリカの予期しない停止の処理」 を参照)。

binlog_error_action が IGNORE_ERROR に設定されている場合、サーバーでこのようなエラーが発生すると、進行中のトランザクションが続行され、エラーがログに記録されてからロギングが停止され、更新の実行が続行されます。 バイナリロギングを再開するには、log_bin を再度有効にする必要があります。これにはサーバーの再起動が必要です。 この設定により、古いバージョンの MySQL との下位互換性が提供されます。

binlog_expire_logs_seconds

バイナリログの有効期限を秒単位で設定します。 有効期限の終了後、バイナリログファイルを自動的に削除できます。 削除は起動時およびバイナリログがフラッシュされるときに発生する可能性があります。 ログのフラッシュは、セクション5.4「MySQL Server ログ」に記載されているように発生します。

デフォルトのバイナリログ有効期限は 2592000 秒で、30 日 (30*24*60*60 秒) です。 デフォルトは、binlog_expire_logs_seconds と非推奨のシステム変数 expire_logs_days のどちらにも起動時に設定された値がない場合に適用されます。 binlog_expire_logs_seconds または expire_logs_days のいずれかの変数にゼロ以外の値が起動時に設定されている場合、この値はバイナリログの有効期限として使用されます。 これらの両方の変数にゼロ以外の値が起動時に設定されている場合、binlog_expire_logs_seconds の値がバイナリログの有効期限として使用され、expire_logs_days の値は警告メッセージとともに無視されます。

バイナリログの自動パージを無効にするには、binlog_expire_logs_seconds に値 0 を明示的に指定し、expire_logs_days に値を指定しないでください。 以前のリリースとの互換性のために、expire_logs_days に値 0 を明示的に指定し、binlog_expire_logs_seconds に値を指定しないと、自動パージも無効になります。 その場合、binlog_expire_logs_seconds のデフォルトは適用されません。

バイナリログファイルを手動で削除するには、PURGE BINARY LOGS ステートメントを使用します。 セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください。

binlog_format

この変数はバイナリロギング形式を設定し、STATEMENT、ROW、MIXED のいずれかが可能です。 セクション17.2.1「レプリケーション形式」を参照してください。

binlog_format は起動時または実行時に設定できますが、後で説明するように、一部の条件下ではこの変数を実行時に変更できないか、レプリケーションが失敗することを除きます。

デフォルトは ROW です。 例外: NDB Cluster では、デフォルトは MIXED です。ステートメントベースのレプリケーションは NDB Cluster ではサポートされません。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

この変数への変更がいつ有効になり、影響はどのくらい長く続くかを管理するルールは、ほかの MySQL サーバーシステム変数の場合と同じです。 詳細は、セクション13.7.6.1「変数代入の SET 構文」を参照してください。

MIXED が指定されている場合、行ベースレプリケーションだけが適切な結果になることが保証されている場合を除き、ステートメントベースレプリケーションが使用されます。 たとえば、これはユーザー定義関数 (UDF) または UUID() 関数がステートメントに含まれているときに発生します。

各バイナリロギング形式が設定されている場合のストアドプログラム (ストアドプロシージャーとストアドファンクション、トリガー、およびイベント) の処理方法の詳細は、セクション25.7「ストアドプログラムバイナリロギング」 を参照してください。

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

これらのいずれかの場合 (または現在のレプリケーション形式を設定しようとする場合) にレプリケーション形式を切り替えようとすると、エラーになります。 ただし、PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format) を使用してレプリケーション形式をいつでも変更できます。これは、このアクションによってランタイムグローバルシステム変数の値が変更されず、サーバーの再起動後にのみ有効になるためです。

一時テーブルが存在する場合、実行時にレプリケーション形式を切り替えることはお勧めしません。一時テーブルはステートメントベースレプリケーションの使用時にのみログに記録されますが、行ベースレプリケーションと混在レプリケーションではログに記録されないためです。

レプリケーションソースサーバーでロギング形式を変更しても、レプリカのロギング形式は一致するように変更されません。 レプリケーションの進行中にレプリケーション形式を切り替えると、レプリカでバイナリロギングが有効になっている場合に問題が発生し、ソースが ROW または MIXED 形式のロギングを使用している間に、変更によってレプリカで STATEMENT 形式のロギングが使用されることがあります。 レプリカは、ROW ロギング形式で受信したバイナリログエントリを独自のバイナリログで使用するために STATEMENT 形式に変換できないため、レプリケーションが失敗する可能性があります。 詳細は、セクション5.4.4.2「バイナリログ形式の設定」を参照してください。

バイナリログ形式は次のサーバーオプションの動作に影響を与えます。

これらの影響の詳細は、個々のオプションの説明に記載されています。

binlog_group_commit_sync_delay

バイナリログファイルをディスクに同期する前にバイナリログのコミットが待機するマイクロ秒数を制御します。 デフォルトでは、binlog_group_commit_sync_delay は 0 に設定されており、これは遅延がないことを意味します。 binlog_group_commit_sync_delay をマイクロ秒遅延に設定すると、必要なグループがグループごとの時間単位が少なくなるため、一度により多くのトランザクションをディスクに同期でき、トランザクションのグループをコミットするための全体的な時間が短縮されます。

sync_binlog=0 または sync_binlog=1 が設定されている場合、binlog_group_commit_sync_delay によって指定された遅延は、同期の前 (または sync_binlog=0 の場合は先に進む前) にすべてのバイナリログコミットグループに適用されます。 sync_binlog が 1 より大きい値 n に設定されている場合、遅延はすべての n バイナリログコミットグループのあとに適用されます。

binlog_group_commit_sync_delay を設定すると、レプリカを持つ (またはフェイルオーバー後に存在する可能性のある) サーバー上のパラレルコミットトランザクションの数を増やすことができるため、レプリカに対するパラレル実行を増やすことができます。 この効果を活用するには、レプリカサーバーに slave_parallel_type=LOGICAL_CLOCK が設定されている必要があります。また、binlog_transaction_dependency_tracking=COMMIT_ORDER も設定されている場合は、この効果が重要になります。 binlog_group_commit_sync_delay の設定をチューニングする場合は、ソースのスループットとレプリカのスループットの両方を考慮することが重要です。

binlog_group_commit_sync_delay を設定すると、バイナリログを持つサーバー (ソースまたはレプリカ) 上のバイナリログへの fsync() 呼び出しの数を減らすこともできます。

binlog_group_commit_sync_delay を設定すると、サーバー上のトランザクションの待機時間が長くなり、クライアントアプリケーションに影響する可能性があることに注意してください。 また、同時実行性の高いワークロードでは、遅延によって競合が増加し、スループットが低下する可能性があります。 通常、遅延を設定する利点は欠点を上回っていますが、最適な設定を決定するには、チューニングを常に実行する必要があります。

binlog_group_commit_sync_no_delay_count

binlog_group_commit_sync_delay で指定された現在の遅延を中断する前に待機するトランザクションの最大数。 binlog_group_commit_sync_delay が 0 に設定されている場合、このオプションは無効です。

binlog_max_flush_queue_time

binlog_max_flush_queue_time は非推奨であり、将来の MySQL リリースでは最終的に削除対象としてマークされます。 以前は、このシステム変数は、グループコミットを続行する前にフラッシュキューからトランザクションの読取りを続行する時間をマイクロ秒単位で制御していました。 効果はなくなりました。

binlog_order_commits

この変数がレプリケーションソースサーバー (デフォルト) で有効になっている場合、ストレージエンジンに発行されるトランザクションコミット命令はシングルスレッド上で直列化されるため、トランザクションは常にバイナリログに書き込まれるのと同じ順序でコミットされます。 この変数を無効にすると、複数のスレッドを使用してトランザクションコミット命令を発行できます。 バイナリロググループのコミットと組み合わせて使用すると、単一のトランザクションのコミット率がスループットのボトルネックになるのを防ぐため、パフォーマンスが向上する可能性があります。

トランザクションは、関連するすべてのストレージエンジンがトランザクションのコミット準備を完了したことを確認した時点で、バイナリログに書き込まれます。 その後、バイナリロググループのコミットロジックは、バイナリログの書き込みが行われたあとにトランザクションのグループをコミットします。 binlog_order_commits が無効になっている場合、このプロセスに複数のスレッドが使用されているため、コミットグループ内のトランザクションはバイナリログ内の順序とは異なる順序でコミットされる可能性があります。 (単一のクライアントからのトランザクションは常に時系列順にコミットされます。) 多くの場合、これは問題ではありません。個別のトランザクションで実行される操作は一貫した結果を生成する必要があり、そうでない場合は、かわりに単一のトランザクションを使用する必要があります。

ソースとマルチスレッドのレプリカのトランザクション履歴が同一であることを確認する場合は、レプリカに slave_preserve_commit_order=1 を設定します。

binlog_rotate_encryption_master_key_at_startup

サーバーの起動時にバイナリログマスターキーをローテーションするかどうかを指定します。 バイナリログマスターキーは、バイナリログファイルおよびサーバー上のリレーログファイルのファイルパスワードを暗号化するために使用されるバイナリログ暗号化鍵です。 バイナリログ暗号化 (binlog_encryption=ON) を有効にしてサーバーをはじめて起動すると、新しいバイナリログ暗号化鍵が生成され、バイナリログマスターキーとして使用されます。 binlog_rotate_encryption_master_key_at_startup システム変数も ON に設定されている場合、サーバーが再起動されるたびにバイナリログ暗号化鍵が生成され、後続のすべてのバイナリログファイルおよびリレーログファイルのバイナリログマスターキーとして使用されます。 binlog_rotate_encryption_master_key_at_startup システム変数が OFF(デフォルト) に設定されている場合、サーバーの再起動後に既存のバイナリログマスターキーが再度使用されます。 バイナリログ暗号化鍵とバイナリログマスターキーの詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。

binlog_row_event_max_size

行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。

このグローバルシステム変数は読取り専用で、サーバーの起動時にのみ設定できます。 したがって、その値を変更するには、SET ステートメントで PERSIST_ONLY キーワードまたは@@persist_only 修飾子を使用する必要があります。

binlog_row_image

MySQL 行ベースレプリケーションの場合、この変数は行イメージをバイナリログに書き込む方法を決定します。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

MySQL 行ベースレプリケーションでは、各行変更イベントに 2 つのイメージ、つまり「前」イメージ (更新される行を検索するときにこれらのカラムが照合される) と「後」イメージ (変更を含む) が含まれます。 通常、MySQL は前イメージと後イメージの両方のためにすべての行 （つまり、すべてのカラム） のログを記録します。 ただし、両方のイメージにすべてのカラムが厳密に含まれている必要はなく、多くの場合、実際に必要なカラムのログのみを記録することでディスク、メモリー、およびネットワーク使用量を節約できます。

前イメージについては、行を一意に識別するために必要な最小カラムセットのログが記録されることのみが必要です。 行を含むテーブルに主キーがある場合、主キーカラムだけがバイナリログに書き込まれます。 そうではなく、テーブルに一意キーがあり、そのカラムのすべてが NOT NULL の場合は、一意キー内のカラムのログのみを記録する必要があります。 (テーブルに NULL カラムなしの主キーまたは一意キーがない場合、すべてのカラムが前イメージで使用され、それらのログが記録される必要があります。) 後イメージでは、実際に変更されたカラムのログのみを記録する必要があります。

binlog_row_image システム変数を使用して、サーバーに完全な行または最小限の行を記録させることができます。 この変数は実際には、次のリストで示す 3 つの可能な値の 1 つを取ることができます。

デフォルト値は full です。

minimal または noblob を使用するときは、ソーステーブルと宛先テーブルの両方について次の条件が true の場合にのみ、所定のテーブルに対して削除と更新が正しく機能することが保証されます。

(つまり、これらのテーブルは同じである必要がありますが、テーブルの主キーの一部でないインデックスがある場合にはそれらは除きます。)

これらの条件が満たされない場合は、宛先テーブル内の主キーカラム値が、削除または更新のための一意一致を提供するために不十分であることが判明する場合があります。 この場合、警告やエラーは発行されず、ソースとレプリカは暗黙的に相違するため、一貫性が損なわれます。

バイナリロギング形式が STATEMENT のときは、この変数を設定しても効果はありません。 binlog_format が MIXED の場合、binlog_row_image の設定は行ベースの形式を使用して記録された変更に適用されますが、この設定はステートメントとして記録された変更には影響しません。

グローバルまたはセッションレベルのいずれかで binlog_row_image を設定しても、暗黙的にコミットされません。これは、トランザクションの進行中にトランザクションに影響を与えずにこの変数を変更できることを意味します。

binlog_row_metadata

行ベースロギングの使用時にバイナリログに追加されるテーブルメタデータの量を構成します。 MINIMAL(デフォルト) に設定すると、SIGNED フラグ、カラム文字セットおよびジオメトリタイプに関連するメタデータのみがログに記録されます。 FULL に設定すると、カラム名、ENUM または SET 文字列値、PRIMARY KEY 情報など、テーブルの完全なメタデータがログに記録されます。

拡張メタデータは、次の目的で使用されます:

binlog_row_value_options

PARTIAL_JSON に設定すると、JSON ドキュメントの小さい部分のみを変更する更新に領域効率のよいバイナリログ形式を使用できるようになります。これにより、行ベースのレプリケーションでは、JSON ドキュメントの変更された部分のみがバイナリログ内の更新のアフターイメージに書き込まれます (完全なドキュメントは書き込まれません)。 これは、JSON_SET()、JSON_REPLACE() および JSON_REMOVE() の任意の順序を使用して JSON カラムを変更する UPDATE ステートメントに対して機能します。 変更にドキュメント全体よりも多くの領域が必要な場合、またはサーバーが部分更新を生成できない場合は、かわりにドキュメント全体が使用されます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

サポートされている値は PARTIAL_JSON のみです。binlog_row_value_options の設定を解除するには、その値を空の文字列に設定します。

binlog_row_value_options=PARTIAL_JSON は、バイナリロギングが有効で、binlog_format が ROW または MIXED に設定されている場合にのみ有効になります。 ステートメントベースレプリケーション always は、binlog_row_value_options に設定された値に関係なく、JSON ドキュメントの変更された部分のみを記録します。 節約される領域の量を最大化するには、このオプションとともに binlog_row_image=NOBLOB または binlog_row_image=MINIMAL を使用します。完全な JSON ドキュメントはビフォアイメージに格納され、部分更新はアフターイメージにのみ格納されるため、binlog_row_image=FULL はこれらのいずれかよりも少ない領域を節約します。

mysqlbinlog 出力には、BINLOG ステートメントを使用して base-64 文字列としてエンコードされたイベントの形式で部分的な JSON 更新が含まれます。 --verbose オプションが指定されている場合、mysqlbinlog は擬似 SQL ステートメントを使用して部分的な JSON 更新を読取り可能な JSON として表示します。

レプリカ上の JSON ドキュメントに変更を適用できない場合、MySQL レプリケーションはエラーを生成します。 これには、パスの検索の失敗も含まれます。 この安全性チェックおよびその他の安全性チェックでも、レプリカ上の JSON ドキュメントがソース上の JSON ドキュメントと相違しており、部分更新が適用されても、理論的にはレプリカ上に有効だが予期しない JSON ドキュメントを生成できることに注意してください。

binlog_rows_query_log_events

このシステム変数は、行ベースのロギングにのみ影響します。 有効にすると、サーバーは行クエリーログイベントなどの情報ログイベントをバイナリログに書き込みます。 この情報は、行の更新から再構築できない場合にソースに対して発行された元のクエリーを取得するなど、デバッグおよび関連する目的で使用できます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

これらの情報イベントは通常、バイナリログを読み取る MySQL プログラムによって無視されるため、バックアップからレプリケートまたは復元するときに問題は発生しません。 これらを表示するには、mysqlbinlog --verbose オプションを -vv または --verbose --verbose として 2 回使用して、冗長性レベルを上げます。

binlog_stmt_cache_size

トランザクション中に発行された非トランザクションステートメントを保持するバイナリログのメモリーバッファーのサイズ。 (log_bin システム変数を ON に設定して) サーバーでバイナリロギングが有効になっている場合、サーバーがトランザクションストレージエンジンをサポートしていれば、クライアントごとに個別のバイナリログトランザクションとステートメントキャッシュが割り当てられます。 トランザクションで使用される非トランザクションステートメントのデータがメモリーバッファ内の領域を超えると、余分なデータが一時ファイルに格納されます。 バイナリログの暗号化がサーバーでアクティブな場合、メモリーバッファは暗号化されませんが、バイナリログキャッシュの保持に使用される一時ファイルは (MySQL 8.0.17 から) 暗号化されます。 各トランザクションがコミットされたあと、バイナリログステートメントキャッシュはメモリーバッファーをクリアし、一時ファイルが使用されている場合は切り捨ててリセットされます。

トランザクション中に大規模な非トランザクションステートメントを頻繁に使用する場合は、一時ファイルへの書込みを削減または排除することで、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。 Binlog_stmt_cache_use および Binlog_stmt_cache_disk_use ステータス変数は、この変数のサイズを調整する場合に役立つ場合があります。 セクション5.4.4「バイナリログ」を参照してください。

binlog_cache_size システム変数はトランザクションキャッシュのサイズを設定します。

binlog_transaction_compression

このサーバー上のバイナリログファイルに書き込まれるトランザクションの圧縮を有効にします。 OFF がデフォルトです。 binlog_transaction_compression_level_zstd システム変数を使用して、圧縮に使用される zstd アルゴリズムのレベルを設定します。

バイナリログのトランザクション圧縮が有効になっている場合、トランザクションペイロードは圧縮され、単一のイベント (Transaction_payload_event) としてバイナリログファイルに書き込まれます。 圧縮されたトランザクションペイロードは、レプリケーションストリームでレプリカ、他のグループレプリケーショングループメンバー、または mysqlbinlog などのクライアントに送信されている間、圧縮状態のままであり、圧縮状態のままリレーログに書き込まれます。 したがって、バイナリログトランザクション圧縮では、トランザクションの作成者と受信者 (およびそのバックアップ) の両方に記憶領域が節約され、トランザクションがサーバーインスタンス間で送信されるときにネットワーク帯域幅が節約されます。

binlog_transaction_compression=ON を直接有効にするには、サーバーでバイナリロギングを有効にする必要があります。 MySQL サーバーインスタンスにバイナリログがない場合、MySQL 8.0.20 からのリリースであれば、binlog_transaction_compression の値に関係なく、圧縮されたトランザクションペイロードを受信、処理および表示できます。 このようなサーバーインスタンスによって受信された圧縮トランザクションペイロードは、圧縮された状態でリレーログに書き込まれるため、レプリケーショントポロジ内の他のサーバーによって実行される圧縮から間接的にメリットが得られます。

このシステム変数は、トランザクションのコンテキスト内では変更できません。 このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

バイナリログのトランザクション圧縮の詳細 (圧縮されているイベントと圧縮されていないイベントの詳細、トランザクション圧縮が使用されている場合の動作の変更など) は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。

binlog_transaction_compression_level_zstd

binlog_transaction_compression システム変数によって有効になる、このサーバー上のバイナリログトランザクション圧縮の圧縮レベルを設定します。 この値は、圧縮作業を決定する整数で、1 (最小作業量) から 22 (最大作業量) までです。 このシステム変数を指定しない場合、圧縮レベルは 3 に設定されます。

圧縮レベルが高くなると、データ圧縮率が高くなり、トランザクションペイロードに必要なストレージ領域およびネットワーク帯域幅が削減されます。 ただし、データ圧縮に必要な労力も増加し、元のサーバーでは時間と CPU およびメモリーリソースがかかります。 圧縮作業の増加には、データ圧縮率の増加と線形関係はありません。

このシステム変数は、トランザクションのコンテキスト内では変更できません。 このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

binlog_transaction_dependency_tracking

マルチスレッドレプリカ (slave_parallel_workers が 0 より大きい値に設定されているレプリカ) を持つレプリケーションソースサーバーの場合、binlog_transaction_dependency_tracking は、レプリカが並列で実行できるトランザクションを判断するのに役立つように、バイナリログにソースが記録する依存性情報のソースを指定します。 指定可能な値は次のとおりです。

WRITESET および WRITESET_SESSION モードでは、COMMIT_ORDER モードで返されるものよりも最適化されていないトランザクション依存性は提供されません。 WRITESET または WRITESET_SESSION を値として設定すると、ソースは、空または部分書込みセットを持つトランザクション、主キーまたは一意キーのないテーブルを更新するトランザクション、および外部キー関係の親テーブルを更新するトランザクションに対して COMMIT_ORDER モードを使用します。

WRITESET または WRITESET_SESSION を binlog_transaction_dependency_tracking の値として設定するには、(OFF に設定されていない) アルゴリズムを指定するように transaction_write_set_extraction を設定する必要があります。 MySQL 8.0 のデフォルトでは、transaction_write_set_extraction は XXHASH64 に設定されています。 transaction_write_set_extraction に選択した値は、binlog_transaction_dependency_tracking の値が WRITESET または WRITESET_SESSION のままである間は再度変更できません。

特定の行を変更した最新のトランザクションについて保持およびチェックされる行ハッシュの数は、binlog_transaction_dependency_history_size の値によって決まります。

グループレプリケーションの場合、binlog_transaction_dependency_tracking=WRITESET_SESSION を設定すると、グループワークロードに応じてグループメンバーのパフォーマンスを向上させることができます。 Group Replication は、binlog_transaction_dependency_tracking に設定された値とは関係なく、リレーログからトランザクションを適用するときに、証明後に独自のパラレル化を実行します。 ただし、binlog_transaction_dependency_tracking の値は、グループレプリケーションメンバーのバイナリログへのトランザクションの書込み方法に影響します。 これらのログ内の依存関係情報は、メンバーがグループに参加または再参加するたびに発生する分散リカバリのドナーバイナリログからの状態転送プロセスを支援するために使用されます。

binlog_transaction_dependency_history_size

メモリーに保持され、特定の行を最後に変更したトランザクションの検索に使用される行ハッシュの数の上限を設定します。 このハッシュ数に達すると、履歴がパージされます。

expire_logs_days

バイナリログファイルを自動的に削除するまでの日数を指定します。expire_logs_days は非推奨であり、将来のリリースで削除される予定です。 代わりに、バイナリログの有効期限を秒単位で設定する binlog_expire_logs_seconds を使用してください。 どちらのシステム変数にも値を設定しない場合、デフォルトの有効期限は 30 日です。 削除は起動時およびバイナリログがフラッシュされるときに発生する可能性があります。 ログのフラッシュは、セクション5.4「MySQL Server ログ」に記載されているように発生します。

binlog_expire_logs_seconds も指定した場合、expire_logs_days にゼロ以外の値を指定すると無視され、かわりにバイナリログの有効期限として binlog_expire_logs_seconds の値が使用されます。 この状況では、警告メッセージが発行されます。 expire_logs_days のゼロ以外の値は、binlog_expire_logs_seconds が指定されていないか、0 として指定されている場合にのみバイナリログの有効期限として適用されます。

バイナリログの自動パージを無効にするには、binlog_expire_logs_seconds に値 0 を明示的に指定し、expire_logs_days に値を指定しないでください。 以前のリリースとの互換性のために、expire_logs_days に値 0 を明示的に指定し、binlog_expire_logs_seconds に値を指定しないと、自動パージも無効になります。 その場合、binlog_expire_logs_seconds のデフォルトは適用されません。

バイナリログファイルを手動で削除するには、PURGE BINARY LOGS ステートメントを使用します。 セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください。

log_bin

サーバー上のバイナリロギングのステータスを表示します。有効 (ON) または無効 (OFF) のいずれかです。 バイナリロギングが有効になっている場合、サーバーは、データを変更するすべてのステートメントをバイナリログに記録します。バイナリログは、バックアップとレプリケーションに使用されます。 ON はバイナリログが使用可能であることを意味し、OFF はバイナリログが使用されていないことを意味します。 --log-bin オプションを使用すると、バイナリログのベース名と場所を指定できます。

以前の MySQL バージョンでは、バイナリロギングはデフォルトで無効になっており、--log-bin オプションを指定した場合は有効になっていました。 MySQL 8.0 からは、--log-bin オプションを指定するかどうかに関係なく、log_bin システム変数が ON に設定されたバイナリロギングがデフォルトで有効になります。 例外は、バイナリロギングがデフォルトで無効になっている場合に、mysqld を使用して --initialize または --initialize-insecure オプションを指定してデータディレクトリを手動で呼び出すことによって、データディレクトリを初期化する場合です。 この場合、--log-bin オプションを指定することでバイナリロギングを有効にできます。

--skip-log-bin または --disable-log-bin オプションが起動時に指定された場合、バイナリロギングは無効になり、log_bin システム変数は OFF に設定されます。 これらのオプションのいずれかが指定され、--log-bin も指定されている場合は、後で指定するオプションが優先されます。

バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。

log_bin_basename

バイナリログファイルのベース名とパスを保持します。これらは --log-bin サーバーオプションで設定できます。 最大可変長は 256 です。 MySQL 8.0 では、--log-bin オプションが指定されていない場合、デフォルトのベース名は binlog です。 MySQL 5.7 との互換性のために、--log-bin オプションが文字列なしまたは空の文字列とともに指定されている場合、デフォルトのベース名は host_name-bin で、ホストマシンの名前が使用されます。 デフォルトの場所はデータディレクトリです。

log_bin_index

バイナリログインデックスファイルのベース名とパスを保持します。これは、--log-bin-index サーバーオプションで設定できます。 最大可変長は 256 です。

log_bin_trust_function_creators

この変数は、バイナリロギングが有効な場合に適用されます。 ストアドファンクションの作成者が、安全でないイベントがバイナリログに書き込まれる原因となるストアドファンクションを作成しないことを信頼できるかどうかを制御します。 0 (デフォルト) に設定した場合、ユーザーは CREATE ROUTINE または ALTER ROUTINE 権限に加えて SUPER 権限を持たないかぎり、ストアドファンクションを作成または変更することが許可されません。 0 に設定することで、関数を DETERMINISTIC 特性で、あるいは READS SQL DATA または NO SQL 特性で宣言する必要があるという制約も強制されます。 変数が 1 に設定された場合、MySQL はストアドファンクション作成にこれらの制約を強制しません。 この変数はトリガー作成にも適用されます。 セクション25.7「ストアドプログラムバイナリロギング」を参照してください。

log_bin_use_v1_row_events

この読取り専用システム変数は非推奨です。 サーバーの起動時にシステム変数を ON に設定すると、MySQL 5.6 の時点でデフォルトであるバージョン 2 バイナリログ行イベントではなく、バージョン 1 バイナリログ行イベントを使用してバイナリログを書き込むことによって、MySQL Server 5.5 以前を実行しているレプリカで行ベースレプリケーションが有効になります。

log_slave_updates

レプリケーションソースサーバーから受信した更新を、レプリカ独自のバイナリログに記録するかどうか。

この変数を有効にすると、レプリカはソースから受信し、レプリケーション SQL スレッドによって実行された更新をレプリカ独自のバイナリログに書き込みます。 バイナリロギングは --log-bin オプションによって制御され、デフォルトで有効になっていますが、更新をログに記録するにはレプリカでも有効にする必要があります。 セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」 を参照してください。--skip-log-bin を指定してバイナリロギングを無効にしないかぎり、log_slave_updates はデフォルトで有効になっています。この場合、MySQL はレプリカ更新ロギングもデフォルトで無効にします。 バイナリロギングが有効になっているときにレプリカ更新ロギングを無効にする必要がある場合は、レプリカサーバーの起動時に --log-slave-updates=OFF を指定します。

log_slave_updates を有効にすると、レプリケーションサーバーをチェーンできます。 たとえば、このようにレプリケーションサーバーをセットアップするとします。

A -> B -> C

ここで、A はレプリカ B のソースとして機能し、B はレプリカ C のソースとして機能します。 これが機能するには、B がソースとレプリカの両方である必要があります。 バイナリロギングが有効で、log_slave_updates が有効になっている場合 (デフォルト設定)、A から受信した更新は B によってバイナリログに記録されるため、C に渡すことができます。

log_statements_unsafe_for_binlog

エラー 1592 が発生した場合、生成された警告をエラーログに追加するかどうかを制御します。

master_verify_checksum

この変数を有効にすると、ソースはチェックサムを検査してバイナリログから読み取られたイベントを検証し、不一致が発生した場合はエラーで停止します。master_verify_checksum はデフォルトで無効になっています。この場合、ソースはバイナリログのイベント長を使用してイベントを検証し、バイナリログから完全なイベントのみが読み取られるようにします。

max_binlog_cache_size

トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはMulti-statement transaction required more than 'max_binlog_cache_size' bytes of storageエラーを生成します。 最小値は 4096 です。 可能な最大値は 16EiB (exbibytes) です。 推奨される最大値は 4G バイトです。これは、MySQL が現在 4G バイトより大きなバイナリログ位置で作業できないという事実によります。

max_binlog_cache_size はトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュの上限値は max_binlog_stmt_cache_size システム変数によって管理されます。

max_binlog_cache_size のセッションの可視性は、binlog_cache_size システム変数の可視性と一致します。つまり、その値を変更すると、値が変更された後に開始される新しいセッションにのみ影響します。

max_binlog_size

バイナリログへの書き込みによって、現在のログファイルサイズがこの変数の値を超えた場合、サーバーはバイナリログをローテーションします (現在のファイルを閉じて、新しいものを開きます)。 最小値は 4096 バイトです。 最大値およびデフォルト値は 1G バイトです。 暗号化バイナリログファイルには、max_binlog_size に含まれる追加の 512 バイトヘッダーがあります。

トランザクションはバイナリログにひとまとまりで書き込まれ、複数のバイナリログ間に分割されることはありません。 このため、大きなトランザクションの場合、max_binlog_size より大きいバイナリログファイルが見られることがあります。

max_relay_log_size が 0 の場合、max_binlog_size の値がリレーログにも適用されます。

GTID がサーバーで使用されている場合、max_binlog_size に到達したときに、システムテーブル mysql.gtid_executed にアクセスして GTID を現在のバイナリログファイルから書き込めないと、バイナリログをローテーションできません。 この状況では、サーバーはその binlog_error_action 設定に従って応答します。 IGNORE_ERROR が設定されている場合、サーバーにエラーが記録され、バイナリロギングが停止されます。または、ABORT_SERVER が設定されている場合、サーバーはシャットダウンします。

max_binlog_stmt_cache_size

トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはエラーを生成します。 最小値は 4096 です。 最大値およびデフォルト値は、32 ビットプラットフォームでは 4G バイト、64 ビットプラットフォームでは 16E バイト (エクサバイト) です。

max_binlog_stmt_cache_size はステートメントキャッシュのみのサイズを設定します。トランザクションキャッシュの上限値は max_binlog_cache_size システム変数によって排他的に管理されます。

original_commit_timestamp

レプリケーションによる内部使用用。 レプリカでトランザクションを再実行する場合、これは元のソースでトランザクションがコミットされた時間に設定され、エポック以降マイクロ秒単位で測定されます。 これにより、元のコミットタイムスタンプをレプリケーショントポロジ全体に伝播できます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、REPLICATION_APPLIER 権限 (セクション17.3.3「レプリケーション権限チェック」 を参照) または制限付きセッション変数の設定に十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要です。 ただし、この変数はユーザーが設定するためのものではなく、レプリケーションインフラストラクチャによって自動的に設定されることに注意してください。

sql_log_bin

この変数は、現在のセッションでバイナリログへのロギングを有効にするかどうかを制御します (バイナリログ自体が有効になっていると仮定します)。 デフォルト値は ON です。 現在のセッションのバイナリロギングを無効または有効にするには、セッション sql_log_bin 変数を OFF または ON に設定します。

レプリカにレプリケートしないソースに変更を加えている間にバイナリロギングを一時的に無効にするには、セッションに対してこの変数を OFF に設定します。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

トランザクションまたはサブクエリー内で sql_log_bin のセッション値を設定することはできません。

「この変数を OFF に設定すると、GTID がバイナリログ内のトランザクションに割り当てられなくなります」。 これは、GTID をレプリケーションに使用している場合、バイナリロギングがあとで再度有効になった場合でも、この時点からログに書き込まれる GTID はその意味で発生したトランザクションを考慮しないため、それらのトランザクションは失われることを意味します。

sync_binlog

MySQL サーバーがバイナリログをディスクに同期する頻度を制御します。

トランザクションで InnoDB を使用するレプリケーション設定で永続性と一貫性を最大限に高めるには、次の設定を使用します:

transaction_write_set_extraction

マルチスレッドレプリカ (slave_parallel_workers が 0 より大きい値に設定されているレプリカ) を持つレプリケーションソースサーバーの場合、binlog_transaction_dependency_tracking は WRITESET または WRITESET_SESSION に設定され、ソース書込みセットから依存性情報を生成します。transaction_write_set_extraction は、トランザクション中に抽出された書込みのハッシュに使用されるアルゴリズムを指定します。このシステム変数の値を変更するには、binlog_format を ROW に設定する必要があります。

WRITESET または WRITESET_SESSION が binlog_transaction_dependency_tracking の値として設定されている場合、transaction_write_set_extraction を設定してアルゴリズムを指定する必要があります (OFF に設定されていません)。 MySQL 8.0 のデフォルトでは、transaction_write_set_extraction は XXHASH64 に設定されています。 binlog_transaction_dependency_tracking の現在の値は WRITESET または WRITESET_SESSION ですが、transaction_write_set_extraction の値は変更できません。

グループレプリケーションの場合、transaction_write_set_extraction を XXHASH64 に設定する必要があります。 トランザクションから書込みを抽出するプロセスは、すべてのグループメンバーの競合検出および証明のためにグループレプリケーションで使用されます。 セクション18.9.1「グループレプリケーションの要件」を参照してください。

MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。