MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
このセクションで説明する mysqld オプションおよびシステム変数を使用して、バイナリログの操作に影響を与えたり、バイナリログにどのステートメントが書き込まれたかを制御したりできます。 バイナリログの追加情報については、セクション5.4.4「バイナリログ」を参照してください。 MySQL サーバーのオプションとシステム変数の使用に関する追加情報については、セクション5.1.7「サーバーコマンドオプション」およびセクション5.1.8「サーバーシステム変数」を参照してください。
次のリストでは、バイナリログを有効化したり構成したりするための起動オプションについて説明します。 バイナリロギングで使用するシステム変数については、このセクションの後半で説明します。
コマンド行形式 | --binlog-row-event-max-size=# |
---|---|
システム変数 (≥ 8.0.14) | binlog_row_event_max_size |
スコープ (≥ 8.0.14) | グローバル |
動的 (≥ 8.0.14) | いいえ |
SET_VAR ヒントの適用 (≥ 8.0.14) |
いいえ |
型 | Integer |
デフォルト値 | 8192 |
最小値 | 256 |
最大値 (64 ビットプラットフォーム) | 18446744073709551615 |
最大値 (32 ビットプラットフォーム) | 4294967295 |
行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。
コマンド行形式 | --log-bin=file_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 |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | ファイル名 |
バイナリログインデックスファイルの名前。バイナリログファイルの名前が含まれます。 デフォルトでは、--log-bin
オプションと拡張子 .index
を使用してバイナリログファイルに指定された値と同じ場所とベース名を持ちます。 --log-bin
を指定しない場合、デフォルトのバイナリログインデックスファイル名は binlog.index
です。 文字列または空の文字列を指定せずに --log-bin
オプションを指定した場合、デフォルトのバイナリログインデックスファイル名は、ホストマシンの名前を使用して
になります。
host_name
-bin.index
バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。
ステートメント選択オプション. 次のリストのオプションは、バイナリログに書き込まれ、レプリケーションソースサーバーによってその複製に送信されるステートメントに影響します。 レプリカには、ソースから受信したどのステートメントを実行または無視するかを制御するオプションもあります。 詳細は、セクション17.1.6.3「Replica Server のオプションと変数」を参照してください。
コマンド行形式 | --binlog-do-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=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 回) 使用します。 データベース名にはカンマを含めることができるため、カンマ区切りリストを指定すると、リストは単一のデータベースの名前として扱われます。
クロスデータベース更新を使用していて、それらの更新ログを記録したくない場合は、このオプションを使用しないでください。
チェックサムオプション. MySQL では、バイナリログチェックサムの読み取りと書き込みがサポートされています。 これらは、ここで示す 2 つのオプションを使用して有効化されます。
レプリカによる (リレーログからの) チェックサムの読み取りを制御するには、--slave-sql-verify-checksum
オプションを使用します。
テストおよびデバッグのオプション. 次のバイナリログオプションは、レプリケーションテストおよびデバッグで使用されます。 これらは通常操作での使用を意図していません。
次の一覧で、バイナリロギングを制御するためのシステム変数について説明します。 これらはサーバー起動時に設定でき、それらの一部は SET
を使用して実行時に変更できます。 バイナリロギングを制御するために使用されるサーバーオプションは、このセクションですでにリストされています。
コマンド行形式 | --binlog-cache-size=# |
---|---|
システム変数 | binlog_cache_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 32768 |
最小値 | 4096 |
最大値 (64 ビットプラットフォーム) | 18446744073709551615 |
最大値 (32 ビットプラットフォーム) | 4294967295 |
トランザクション中にバイナリログに対する変更を保持するメモリーバッファーのサイズ。 (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=name |
---|---|
システム変数 | binlog_checksum |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 文字列 |
デフォルト値 | CRC32 |
有効な値 |
|
この変数を有効にすると、ソースは各イベントのチェックサムをバイナリログに書き込みます。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
コマンド行形式 | --binlog-direct-non-transactional-updates[={OFF|ON}] |
---|---|
システム変数 | binlog_direct_non_transactional_updates |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
同時実行性の問題のため、トランザクションにトランザクションテーブルと非トランザクションテーブルの両方に対する更新が含まれる場合、レプリカに一貫性がなくなる可能性があります。 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
に設定され、与えられたステートメントが行ベース形式で複製されるときは、この変数は効果がありません。
この変数を有効にする前に、トランザクションおよび非トランザクションテーブルの間に依存関係がないことを確認する必要があります。このような依存関係の例は、ステートメント INSERT INTO myisam_table SELECT * FROM innodb_table
です。 そうしないと、このようなステートメントによってレプリカがソースと相違する可能性があります。
バイナリログ形式が ROW
または MIXED
の場合、この変数は無効です。
コマンド行形式 | --binlog-encryption[={OFF|ON}] |
---|---|
導入 | 8.0.14 |
システム変数 | binlog_encryption |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
このサーバー上のバイナリログファイルおよびリレーログファイルの暗号化を有効にします。 OFF
がデフォルトです。 ON
は、バイナリログファイルおよびリレーログファイルの暗号化をオンに設定します。 暗号化を有効にするためにバイナリロギングをサーバー上で有効にする必要はないため、バイナリログのないレプリカ上のリレーログファイルを暗号化できます。 暗号化を使用するには、MySQL Server 鍵リングサービスを提供するように鍵リングプラグインをインストールして構成する必要があります。 これを行う手順は、セクション6.4.4「MySQL キーリング」 を参照してください。 サポートされている任意のキーリングプラグインを使用して、バイナリログ暗号化鍵を格納できます。
バイナリログ暗号化を有効にしてサーバーをはじめて起動すると、バイナリログとリレーログが初期化される前に新しいバイナリログ暗号化鍵が生成されます。 このキーは、各バイナリログファイル (サーバーでバイナリロギングが有効になっている場合) およびリレーログファイル (サーバーにレプリケーションチャネルがある場合) のファイルパスワードを暗号化するために使用され、ファイルパスワードから生成された以降の鍵を使用してファイル内のデータが暗号化されます。 リレーログファイルは、グループレプリケーションアプライヤチャネルや暗号化のアクティブ化後に作成される新しいチャネルなど、すべてのチャネルに対して暗号化されます。 バイナリログインデックスファイルとリレーログインデックスファイルは暗号化されません。
サーバーの実行中に暗号化をアクティブ化すると、その時点で新しいバイナリログ暗号化鍵が生成されます。 例外は、以前にサーバー上で暗号化がアクティブであり、その後無効になっていた場合です。その場合、以前に使用されていたバイナリログ暗号化鍵が再度使用されます。 バイナリログファイルとリレーログファイルはただちにローテーションされ、新しいファイルとそれ以降のすべてのバイナリログファイルおよびリレーログファイルのファイルパスワードは、このバイナリログ暗号化鍵を使用して暗号化されます。 既存のバイナリログファイルとリレーログファイルがサーバー上にまだ存在する場合、それらは自動的に暗号化されませんが、不要になった場合はパージできます。
binlog_encryption
システム変数を OFF
に変更して暗号化を非アクティブにすると、バイナリログファイルとリレーログファイルはただちにローテーションされ、それ以降のすべてのロギングは暗号化されません。 以前に暗号化されたファイルは自動的に復号化されませんが、サーバーはそれらを読み取ることができます。 サーバーの実行中に暗号化をアクティブ化または非アクティブ化するには、BINLOG_ENCRYPTION_ADMIN
権限 (または非推奨の SUPER
権限) が必要です。 グループレプリケーションアプライヤチャネルはリレーログローテーションリクエストに含まれないため、これらのチャネルの暗号化されていないロギングは、ログが通常の使用でローテーションされるまで開始されません。
バイナリログファイルとリレーログファイルの暗号化の詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。
コマンド行形式 | --binlog-error-action[=value] |
---|---|
システム変数 | binlog_error_action |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ABORT_SERVER |
有効な値 |
|
バイナリログへの書き込み、フラッシュ、同期ができないなどのエラーがサーバーで発生した場合に何が起こるかを制御します。これにより、ソースバイナリログが矛盾し、レプリカが同期を失う可能性があります。
この変数のデフォルトは ABORT_SERVER
で、バイナリログでこのようなエラーが発生するたびに、サーバーはロギングを停止してシャットダウンします。 再起動時に、予期しないサーバーが停止した場合と同様にリカバリが続行されます (セクション17.4.2「レプリカの予期しない停止の処理」 を参照)。
binlog_error_action
が IGNORE_ERROR
に設定されている場合、サーバーでこのようなエラーが発生すると、進行中のトランザクションが続行され、エラーがログに記録されてからロギングが停止され、更新の実行が続行されます。 バイナリロギングを再開するには、log_bin
を再度有効にする必要があります。これにはサーバーの再起動が必要です。 この設定により、古いバージョンの MySQL との下位互換性が提供されます。
コマンド行形式 | --binlog-expire-logs-seconds=# |
---|---|
システム変数 | binlog_expire_logs_seconds |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 2592000 |
最小値 | 0 |
最大値 | 4294967295 |
バイナリログの有効期限を秒単位で設定します。 有効期限の終了後、バイナリログファイルを自動的に削除できます。 削除は起動時およびバイナリログがフラッシュされるときに発生する可能性があります。 ログのフラッシュは、セクション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=format |
---|---|
システム変数 | binlog_format |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ROW |
有効な値 |
|
この変数はバイナリロギング形式を設定し、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「ストアドプログラムバイナリロギング」 を参照してください。
レプリケーション形式を実行時に切り替えることができない例外もあります。
レプリケーション形式は、ストアドファンクションまたはトリガー内から変更できません。
セッションにオープン一時テーブルがある場合、セッション (SET @@SESSION.binlog_format
) のレプリケーション形式は変更できません。
いずれかのレプリケーションチャネルにオープン一時テーブルがある場合、レプリケーション形式はグローバルに変更できません (SET @@GLOBAL.binlog_format
または SET @@PERSIST.binlog_format
)。
レプリケーションチャネルアプライヤスレッドが現在実行されている場合、レプリケーション形式はグローバルに変更できません (SET @@GLOBAL.binlog_format
または SET @@PERSIST.binlog_format
)。
これらのいずれかの場合 (または現在のレプリケーション形式を設定しようとする場合) にレプリケーション形式を切り替えようとすると、エラーになります。 ただし、PERSIST_ONLY
(SET @@PERSIST_ONLY.binlog_format
) を使用してレプリケーション形式をいつでも変更できます。これは、このアクションによってランタイムグローバルシステム変数の値が変更されず、サーバーの再起動後にのみ有効になるためです。
一時テーブルが存在する場合、実行時にレプリケーション形式を切り替えることはお勧めしません。一時テーブルはステートメントベースレプリケーションの使用時にのみログに記録されますが、行ベースレプリケーションと混在レプリケーションではログに記録されないためです。
レプリケーションソースサーバーでロギング形式を変更しても、レプリカのロギング形式は一致するように変更されません。 レプリケーションの進行中にレプリケーション形式を切り替えると、レプリカでバイナリロギングが有効になっている場合に問題が発生し、ソースが ROW
または MIXED
形式のロギングを使用している間に、変更によってレプリカで STATEMENT
形式のロギングが使用されることがあります。 レプリカは、ROW
ロギング形式で受信したバイナリログエントリを独自のバイナリログで使用するために STATEMENT
形式に変換できないため、レプリケーションが失敗する可能性があります。 詳細は、セクション5.4.4.2「バイナリログ形式の設定」を参照してください。
バイナリログ形式は次のサーバーオプションの動作に影響を与えます。
--replicate-do-db
--replicate-ignore-db
--binlog-do-db
--binlog-ignore-db
これらの影響の詳細は、個々のオプションの説明に記載されています。
binlog_group_commit_sync_delay
コマンド行形式 | --binlog-group-commit-sync-delay=# |
---|---|
システム変数 | binlog_group_commit_sync_delay |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 1000000 |
バイナリログファイルをディスクに同期する前にバイナリログのコミットが待機するマイクロ秒数を制御します。 デフォルトでは、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-no-delay-count=# |
---|---|
システム変数 | binlog_group_commit_sync_no_delay_count |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 1000000 |
binlog_group_commit_sync_delay
で指定された現在の遅延を中断する前に待機するトランザクションの最大数。 binlog_group_commit_sync_delay
が 0 に設定されている場合、このオプションは無効です。
コマンド行形式 | --binlog-max-flush-queue-time=# |
---|---|
非推奨 | はい |
システム変数 | binlog_max_flush_queue_time |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 100000 |
binlog_max_flush_queue_time
は非推奨であり、将来の MySQL リリースでは最終的に削除対象としてマークされます。 以前は、このシステム変数は、グループコミットを続行する前にフラッシュキューからトランザクションの読取りを続行する時間をマイクロ秒単位で制御していました。 効果はなくなりました。
コマンド行形式 | --binlog-order-commits[={OFF|ON}] |
---|---|
システム変数 | binlog_order_commits |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | ON |
この変数がレプリケーションソースサーバー (デフォルト) で有効になっている場合、ストレージエンジンに発行されるトランザクションコミット命令はシングルスレッド上で直列化されるため、トランザクションは常にバイナリログに書き込まれるのと同じ順序でコミットされます。 この変数を無効にすると、複数のスレッドを使用してトランザクションコミット命令を発行できます。 バイナリロググループのコミットと組み合わせて使用すると、単一のトランザクションのコミット率がスループットのボトルネックになるのを防ぐため、パフォーマンスが向上する可能性があります。
トランザクションは、関連するすべてのストレージエンジンがトランザクションのコミット準備を完了したことを確認した時点で、バイナリログに書き込まれます。 その後、バイナリロググループのコミットロジックは、バイナリログの書き込みが行われたあとにトランザクションのグループをコミットします。 binlog_order_commits
が無効になっている場合、このプロセスに複数のスレッドが使用されているため、コミットグループ内のトランザクションはバイナリログ内の順序とは異なる順序でコミットされる可能性があります。 (単一のクライアントからのトランザクションは常に時系列順にコミットされます。) 多くの場合、これは問題ではありません。個別のトランザクションで実行される操作は一貫した結果を生成する必要があり、そうでない場合は、かわりに単一のトランザクションを使用する必要があります。
ソースとマルチスレッドのレプリカのトランザクション履歴が同一であることを確認する場合は、レプリカに slave_preserve_commit_order=1
を設定します。
binlog_rotate_encryption_master_key_at_startup
コマンド行形式 | --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}] |
---|---|
導入 | 8.0.14 |
システム変数 | binlog_rotate_encryption_master_key_at_startup |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
サーバーの起動時にバイナリログマスターキーをローテーションするかどうかを指定します。 バイナリログマスターキーは、バイナリログファイルおよびサーバー上のリレーログファイルのファイルパスワードを暗号化するために使用されるバイナリログ暗号化鍵です。 バイナリログ暗号化 (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=# |
---|---|
システム変数 (≥ 8.0.14) | binlog_row_event_max_size |
スコープ (≥ 8.0.14) | グローバル |
動的 (≥ 8.0.14) | いいえ |
SET_VAR ヒントの適用 (≥ 8.0.14) |
いいえ |
型 | Integer |
デフォルト値 | 8192 |
最小値 | 256 |
最大値 (64 ビットプラットフォーム) | 18446744073709551615 |
最大値 (32 ビットプラットフォーム) | 4294967295 |
行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。
このグローバルシステム変数は読取り専用で、サーバーの起動時にのみ設定できます。 したがって、その値を変更するには、SET
ステートメントで PERSIST_ONLY
キーワードまたは@@persist_only
修飾子を使用する必要があります。
コマンド行形式 | --binlog-row-image=image_type |
---|---|
システム変数 | binlog_row_image |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | full |
有効な値 |
|
MySQL 行ベースレプリケーションの場合、この変数は行イメージをバイナリログに書き込む方法を決定します。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
MySQL 行ベースレプリケーションでは、各行変更イベントに 2 つのイメージ、つまり「前」イメージ (更新される行を検索するときにこれらのカラムが照合される) と「後」イメージ (変更を含む) が含まれます。 通常、MySQL は前イメージと後イメージの両方のためにすべての行 (つまり、すべてのカラム) のログを記録します。 ただし、両方のイメージにすべてのカラムが厳密に含まれている必要はなく、多くの場合、実際に必要なカラムのログのみを記録することでディスク、メモリー、およびネットワーク使用量を節約できます。
行を削除するときは、削除後に伝達する変更後の値がないため、前イメージのみのログが記録されます。 行を挿入するときは、照合される既存の行がないため、後イメージのみのログが記録されます。 行を更新するときのみ、前イメージと後イメージの両方が必要で、両方がバイナリログに書き込まれます。
前イメージについては、行を一意に識別するために必要な最小カラムセットのログが記録されることのみが必要です。 行を含むテーブルに主キーがある場合、主キーカラムだけがバイナリログに書き込まれます。 そうではなく、テーブルに一意キーがあり、そのカラムのすべてが NOT NULL
の場合は、一意キー内のカラムのログのみを記録する必要があります。 (テーブルに NULL
カラムなしの主キーまたは一意キーがない場合、すべてのカラムが前イメージで使用され、それらのログが記録される必要があります。) 後イメージでは、実際に変更されたカラムのログのみを記録する必要があります。
binlog_row_image
システム変数を使用して、サーバーに完全な行または最小限の行を記録させることができます。 この変数は実際には、次のリストで示す 3 つの可能な値の 1 つを取ることができます。
full
: 前イメージと後イメージの両方にすべてのカラムのログを記録します。
minimal
: 変更する行を識別するために必要なビフォアイメージのカラムのみをログに記録します。SQL ステートメントで値が指定されたか、自動増分によって生成されたアフターイメージのカラムのみをログに記録します。
noblob
: すべてのカラム (full
と同じ) のログを記録しますが、行の識別に必要がない、または変更されなかった BLOB
および TEXT
カラムは除きます。
この変数は NDB Cluster ではサポートされていません。設定しても NDB
テーブルのロギングには影響しません。
デフォルト値は full
です。
minimal
または noblob
を使用するときは、ソーステーブルと宛先テーブルの両方について次の条件が true の場合にのみ、所定のテーブルに対して削除と更新が正しく機能することが保証されます。
すべてのカラムが同じ順番で存在する必要があります。それぞれのカラムがもう一方のテーブル内の対応するものと同じデータ型を使用する必要があります。
これらのテーブルの主キー定義が同じである必要があります。
(つまり、これらのテーブルは同じである必要がありますが、テーブルの主キーの一部でないインデックスがある場合にはそれらは除きます。)
これらの条件が満たされない場合は、宛先テーブル内の主キーカラム値が、削除または更新のための一意一致を提供するために不十分であることが判明する場合があります。 この場合、警告やエラーは発行されず、ソースとレプリカは暗黙的に相違するため、一貫性が損なわれます。
バイナリロギング形式が STATEMENT
のときは、この変数を設定しても効果はありません。 binlog_format
が MIXED
の場合、binlog_row_image
の設定は行ベースの形式を使用して記録された変更に適用されますが、この設定はステートメントとして記録された変更には影響しません。
グローバルまたはセッションレベルのいずれかで binlog_row_image
を設定しても、暗黙的にコミットされません。これは、トランザクションの進行中にトランザクションに影響を与えずにこの変数を変更できることを意味します。
コマンド行形式 | --binlog-row-metadata=metadata_type |
---|---|
システム変数 | binlog_row_metadata |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | MINIMAL |
有効な値 |
|
行ベースロギングの使用時にバイナリログに追加されるテーブルメタデータの量を構成します。 MINIMAL
(デフォルト) に設定すると、SIGNED
フラグ、カラム文字セットおよびジオメトリタイプに関連するメタデータのみがログに記録されます。 FULL
に設定すると、カラム名、ENUM
または SET
文字列値、PRIMARY KEY
情報など、テーブルの完全なメタデータがログに記録されます。
拡張メタデータは、次の目的で使用されます:
レプリカは、テーブル構造がソースと異なる場合、メタデータを使用してデータを転送します。
外部ソフトウェアでは、メタデータを使用して行イベントをデコードし、データウェアハウスなどの外部データベースにデータを格納できます。
コマンド行形式 | --binlog-row-value-options=# |
---|---|
システム変数 | binlog_row_value_options |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Set |
デフォルト値 | '' |
有効な値 | PARTIAL_JSON |
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[={OFF|ON}] |
---|---|
システム変数 | binlog_rows_query_log_events |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
このシステム変数は、行ベースのロギングにのみ影響します。 有効にすると、サーバーは行クエリーログイベントなどの情報ログイベントをバイナリログに書き込みます。 この情報は、行の更新から再構築できない場合にソースに対して発行された元のクエリーを取得するなど、デバッグおよび関連する目的で使用できます。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
これらの情報イベントは通常、バイナリログを読み取る MySQL プログラムによって無視されるため、バックアップからレプリケートまたは復元するときに問題は発生しません。 これらを表示するには、mysqlbinlog --verbose
オプションを -vv
または --verbose --verbose
として 2 回使用して、冗長性レベルを上げます。
コマンド行形式 | --binlog-stmt-cache-size=# |
---|---|
システム変数 | binlog_stmt_cache_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 32768 |
最小値 | 4096 |
最大値 (64 ビットプラットフォーム) | 18446744073709551615 |
最大値 (32 ビットプラットフォーム) | 4294967295 |
トランザクション中に発行された非トランザクションステートメントを保持するバイナリログのメモリーバッファーのサイズ。 (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
コマンド行形式 | --binlog-transaction-compression[={OFF|ON}] |
---|---|
導入 | 8.0.20 |
システム変数 | binlog_transaction_compression |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
このサーバー上のバイナリログファイルに書き込まれるトランザクションの圧縮を有効にします。 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-level-zstd=# |
---|---|
導入 | 8.0.20 |
システム変数 | binlog_transaction_compression_level_zstd |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 3 |
最小値 | 1 |
最大値 | 22 |
binlog_transaction_compression
システム変数によって有効になる、このサーバー上のバイナリログトランザクション圧縮の圧縮レベルを設定します。 この値は、圧縮作業を決定する整数で、1 (最小作業量) から 22 (最大作業量) までです。 このシステム変数を指定しない場合、圧縮レベルは 3 に設定されます。
圧縮レベルが高くなると、データ圧縮率が高くなり、トランザクションペイロードに必要なストレージ領域およびネットワーク帯域幅が削減されます。 ただし、データ圧縮に必要な労力も増加し、元のサーバーでは時間と CPU およびメモリーリソースがかかります。 圧縮作業の増加には、データ圧縮率の増加と線形関係はありません。
このシステム変数は、トランザクションのコンテキスト内では変更できません。 このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
binlog_transaction_dependency_tracking
コマンド行形式 | --binlog-transaction-dependency-tracking=value |
---|---|
システム変数 | binlog_transaction_dependency_tracking |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | COMMIT_ORDER |
有効な値 |
|
マルチスレッドレプリカ (slave_parallel_workers
が 0 より大きい値に設定されているレプリカ) を持つレプリケーションソースサーバーの場合、binlog_transaction_dependency_tracking
は、レプリカが並列で実行できるトランザクションを判断するのに役立つように、バイナリログにソースが記録する依存性情報のソースを指定します。 指定可能な値は次のとおりです。
COMMIT_ORDER
: 依存性情報は、ソースコミットタイムスタンプから生成されます。 これはデフォルトです。
WRITESET
: 依存性情報はソース書込みセットから生成され、異なるタプルを書き込むトランザクションはパラレル化できます。
WRITESET_SESSION
: 依存性情報はソース書込みセットから生成され、異なるタプルを書き込むトランザクションはパラレル化できますが、同じセッションからの 2 つの更新を並べ替えることはできません。
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
コマンド行形式 | --binlog-transaction-dependency-history-size=# |
---|---|
システム変数 | binlog_transaction_dependency_history_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 25000 |
最小値 | 1 |
最大値 | 1000000 |
メモリーに保持され、特定の行を最後に変更したトランザクションの検索に使用される行ハッシュの数の上限を設定します。 このハッシュ数に達すると、履歴がパージされます。
コマンド行形式 | --expire-logs-days=# |
---|---|
非推奨 | はい |
システム変数 | expire_logs_days |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 99 |
バイナリログファイルを自動的に削除するまでの日数を指定します。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 |
---|---|
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
サーバー上のバイナリロギングのステータスを表示します。有効 (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 |
---|---|
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | ファイル名 |
バイナリログファイルのベース名とパスを保持します。これらは --log-bin
サーバーオプションで設定できます。 最大可変長は 256 です。 MySQL 8.0 では、--log-bin
オプションが指定されていない場合、デフォルトのベース名は binlog
です。 MySQL 5.7 との互換性のために、--log-bin
オプションが文字列なしまたは空の文字列とともに指定されている場合、デフォルトのベース名は
で、ホストマシンの名前が使用されます。 デフォルトの場所はデータディレクトリです。
host_name
-bin
コマンド行形式 | --log-bin-index=file_name |
---|---|
システム変数 | log_bin_index |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | ファイル名 |
バイナリログインデックスファイルのベース名とパスを保持します。これは、--log-bin-index
サーバーオプションで設定できます。 最大可変長は 256 です。
log_bin_trust_function_creators
コマンド行形式 | --log-bin-trust-function-creators[={OFF|ON}] |
---|---|
システム変数 | log_bin_trust_function_creators |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
この変数は、バイナリロギングが有効な場合に適用されます。 ストアドファンクションの作成者が、安全でないイベントがバイナリログに書き込まれる原因となるストアドファンクションを作成しないことを信頼できるかどうかを制御します。 0 (デフォルト) に設定した場合、ユーザーは CREATE ROUTINE
または ALTER ROUTINE
権限に加えて SUPER
権限を持たないかぎり、ストアドファンクションを作成または変更することが許可されません。 0 に設定することで、関数を DETERMINISTIC
特性で、あるいは READS SQL DATA
または NO SQL
特性で宣言する必要があるという制約も強制されます。 変数が 1 に設定された場合、MySQL はストアドファンクション作成にこれらの制約を強制しません。 この変数はトリガー作成にも適用されます。 セクション25.7「ストアドプログラムバイナリロギング」を参照してください。
コマンド行形式 | --log-bin-use-v1-row-events[={OFF|ON}] |
---|---|
非推奨 | 8.0.18 |
システム変数 | log_bin_use_v1_row_events |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
この読取り専用システム変数は非推奨です。 サーバーの起動時にシステム変数を ON
に設定すると、MySQL 5.6 の時点でデフォルトであるバージョン 2 バイナリログ行イベントではなく、バージョン 1 バイナリログ行イベントを使用してバイナリログを書き込むことによって、MySQL Server 5.5 以前を実行しているレプリカで行ベースレプリケーションが有効になります。
コマンド行形式 | --log-slave-updates[={OFF|ON}] |
---|---|
システム変数 | log_slave_updates |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | ON |
レプリケーションソースサーバーから受信した更新を、レプリカ独自のバイナリログに記録するかどうか。
この変数を有効にすると、レプリカはソースから受信し、レプリケーション 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
コマンド行形式 | --log-statements-unsafe-for-binlog[={OFF|ON}] |
---|---|
システム変数 | log_statements_unsafe_for_binlog |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | ON |
エラー 1592 が発生した場合、生成された警告をエラーログに追加するかどうかを制御します。
コマンド行形式 | --master-verify-checksum[={OFF|ON}] |
---|---|
システム変数 | master_verify_checksum |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
この変数を有効にすると、ソースはチェックサムを検査してバイナリログから読み取られたイベントを検証し、不一致が発生した場合はエラーで停止します。master_verify_checksum
はデフォルトで無効になっています。この場合、ソースはバイナリログのイベント長を使用してイベントを検証し、バイナリログから完全なイベントのみが読み取られるようにします。
コマンド行形式 | --max-binlog-cache-size=# |
---|---|
システム変数 | max_binlog_cache_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 18446744073709551615 |
最小値 | 4096 |
最大値 | 18446744073709551615 |
トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーは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=# |
---|---|
システム変数 | max_binlog_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 1073741824 |
最小値 | 4096 |
最大値 | 1073741824 |
バイナリログへの書き込みによって、現在のログファイルサイズがこの変数の値を超えた場合、サーバーはバイナリログをローテーションします (現在のファイルを閉じて、新しいものを開きます)。 最小値は 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=# |
---|---|
システム変数 | max_binlog_stmt_cache_size |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 18446744073709547520 |
最小値 | 4096 |
最大値 | 18446744073709547520 |
トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはエラーを生成します。 最小値は 4096 です。 最大値およびデフォルト値は、32 ビットプラットフォームでは 4G バイト、64 ビットプラットフォームでは 16E バイト (エクサバイト) です。
max_binlog_stmt_cache_size
はステートメントキャッシュのみのサイズを設定します。トランザクションキャッシュの上限値は max_binlog_cache_size
システム変数によって排他的に管理されます。
システム変数 | original_commit_timestamp |
---|---|
スコープ | セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 数値 |
レプリケーションによる内部使用用。 レプリカでトランザクションを再実行する場合、これは元のソースでトランザクションがコミットされた時間に設定され、エポック以降マイクロ秒単位で測定されます。 これにより、元のコミットタイムスタンプをレプリケーショントポロジ全体に伝播できます。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、REPLICATION_APPLIER
権限 (セクション17.3.3「レプリケーション権限チェック」 を参照) または制限付きセッション変数の設定に十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要です。 ただし、この変数はユーザーが設定するためのものではなく、レプリケーションインフラストラクチャによって自動的に設定されることに注意してください。
システム変数 | sql_log_bin |
---|---|
スコープ | セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | ON |
この変数は、現在のセッションでバイナリログへのロギングを有効にするかどうかを制御します (バイナリログ自体が有効になっていると仮定します)。 デフォルト値は ON
です。 現在のセッションのバイナリロギングを無効または有効にするには、セッション sql_log_bin
変数を OFF
または ON
に設定します。
レプリカにレプリケートしないソースに変更を加えている間にバイナリロギングを一時的に無効にするには、セッションに対してこの変数を OFF
に設定します。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
トランザクションまたはサブクエリー内で sql_log_bin
のセッション値を設定することはできません。
「この変数を OFF
に設定すると、GTID がバイナリログ内のトランザクションに割り当てられなくなります」。 これは、GTID をレプリケーションに使用している場合、バイナリロギングがあとで再度有効になった場合でも、この時点からログに書き込まれる GTID はその意味で発生したトランザクションを考慮しないため、それらのトランザクションは失われることを意味します。
コマンド行形式 | --sync-binlog=# |
---|---|
システム変数 | sync_binlog |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 1 |
最小値 | 0 |
最大値 | 4294967295 |
MySQL サーバーがバイナリログをディスクに同期する頻度を制御します。
sync_binlog=0
: MySQL サーバーによるバイナリログのディスクへの同期を無効にします。 代わりに、MySQL サーバーは、ほかのファイルの場合と同様に、バイナリログをディスクにフラッシュするためにオペレーティングシステムに依存します。 この設定は最高のパフォーマンスを提供しますが、電源障害またはオペレーティングシステムがクラッシュした場合は、バイナリログに同期されていないトランザクションがサーバーによってコミットされている可能性があります。
sync_binlog=1
: トランザクションがコミットされる前にバイナリログをディスクに同期できるようにします。 これは最も安全な設定ですが、ディスク書込み数が増加したためにパフォーマンスに悪影響を与える可能性があります。 電源障害またはオペレーティングシステムがクラッシュした場合、バイナリログから欠落しているトランザクションは準備完了状態にすぎません。 これにより、自動回復ルーチンはトランザクションをロールバックでき、バイナリログからトランザクションが失われないことが保証されます。
sync_binlog=
(N
N
は 0 または 1 以外の値): バイナリログは、N
バイナリログコミットグループが収集されたあとにディスクに同期されます。 電源障害またはオペレーティングシステムがクラッシュした場合は、バイナリログにフラッシュされていないトランザクションがサーバーによってコミットされている可能性があります。 この設定は、ディスク書込み数が増加したため、パフォーマンスに悪影響を与える可能性があります。 値を大きくするとパフォーマンスは向上しますが、データ損失のリスクは高くなります。
トランザクションで InnoDB
を使用するレプリケーション設定で永続性と一貫性を最大限に高めるには、次の設定を使用します:
sync_binlog=1
。
innodb_flush_log_at_trx_commit=1
。
多くのオペレーティングシステムや一部のディスクハードウェアは、ディスクへのフラッシュ操作を行なったと欺きます。 フラッシュが行われていなくても、行われたと mysqld に通知される可能性があります。 この場合、推奨設定であってもトランザクションの永続性は保証されず、最悪の場合は停電によって InnoDB
データが破損する可能性があります。 バッテリーバックアップのディスクキャッシュを SCSI ディスクコントローラ内やディスク自体で使用すると、ファイルフラッシュの速度が上がり、操作が安全になります。 ハードウェアキャッシュ内のディスク書き込みのキャッシュを無効にすることもできます。
transaction_write_set_extraction
コマンド行形式 | --transaction-write-set-extraction[=value] |
---|---|
システム変数 | transaction_write_set_extraction |
スコープ | グローバル、セッション |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | XXHASH64 |
有効な値 |
|
マルチスレッドレプリカ (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「システム変数権限」を参照してください。