--master-info-file=file_name

このオプションの使用は非推奨になりました。 master_info_repository=FILE が設定されている場合は、レプリカ接続メタデータリポジトリのファイル名を設定するために使用されていました。接続メタデータリポジトリのファイルの使用がクラッシュセーフテーブルに置き換えられたため、--master-info-file および master_info_repository システム変数の使用は非推奨になりました。 接続メタデータリポジトリの詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」 を参照してください。

--master-retry-count=count

レプリカがソースへの再接続を試行してから中止する回数。 デフォルト値は 86400 回です。 値 0 は「「無限」」を意味し、レプリカは永久に接続を試みます。 再接続の試行は、レプリカが (slave_net_timeout システム変数で指定された) 接続タイムアウトに達したときに、ソースからデータまたはハートビートシグナルを受信せずにトリガーされます。 再接続は、CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO ステートメントの SOURCE_CONNECT_RETRY | MASTER_CONNECT_RETRY オプションで設定された間隔 (デフォルトは 60 秒ごと) で試行されます。

このオプションは非推奨です。将来の MySQL リリースで削除される予定です。 かわりに、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_RETRY_COUNT | MASTER_RETRY_COUNT オプションを使用してください。

--max-relay-log-size=size

このサイズで、サーバーはリレーログファイルを自動的にローテーションします。 この値がゼロでない場合は、サイズがこの値を超えたときにリレーログは自動的にローテーションされます。 この値がゼロ (デフォルト) の場合、リレーログローテーションが発生するサイズは max_binlog_size の値によって決められます。 詳細は、セクション17.2.4.1「リレーログ」を参照してください。

--relay-log-purge={0|1}

リレーログファイルが不要になるとすぐに自動的にパージすることを無効または有効にします。 デフォルト値は 1 (有効)です。 これは SET GLOBAL relay_log_purge = N で動的に変更できるグローバル変数です。 --relay-log-recovery オプションを有効にするときにリレーログのパージを無効にすると、データの整合性が損なわれるため、クラッシュセーフではありません。

--relay-log-space-limit=size

このオプションは、レプリカ上のすべてのリレーログの合計サイズの上限をバイト単位で設定します。 値 0 は 「制限なし」を表します これは、ディスク容量が限られたレプリカサーバーホストに役立ちます。 制限に達すると、SQL スレッドがいくつかの未使用のリレーログをキャッチアップして削除するまで、I/O スレッドはソースサーバーからのバイナリログイベントの読み取りを停止します。 この制限は絶対ではありません。SQL スレッドがリレーログを削除する前により多くのイベントを必要とする場合があります。 その場合、SQL スレッドが一部のリレーログを削除できるようになるまで I/O スレッドは制限を超えます。そうしないとデッドロックになるためです。 --relay-log-space-limit を --max-relay-log-size (または --max-relay-log-size が 0 の場合は --max-binlog-size) の値の 2 倍未満に設定しないでください。 その場合、I/O スレッドが空き領域を待機する可能性があります。--relay-log-space-limit を超えたけれども、SQL スレッドはパージするリレーログを持たず、I/O スレッドを満たすことができないためです。 この場合、I/O スレッドは強制的に --relay-log-space-limit を一時的に無視します。

--replicate-do-db=db_name

データベースの名前を使用してレプリケーションフィルタを作成します。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_DO_DB を使用しても作成できます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-do-db:channel_1 :db_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

このレプリケーションフィルタの正確な効果は、ステートメントベースレプリケーションと行ベースレプリケーションのどちらが使用されているかによって異なります。

ステートメントベースのレプリケーション.  レプリケーション SQL スレッドに、デフォルトデータベース (つまり、USE によって選択されたデータベース) が db_name であるステートメントにレプリケーションを制限するように指示します。 複数のデータベースを指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。ただし、このようにすると別のデータベースは選択される (またはデータベースが選択されない) けれども、UPDATE some_db.some_table SET foo='bar' などのクロスデータベースステートメントを複製しません。

ステートメントベースレプリケーションの使用時に予想どおりに機能しないことの例: レプリカが --replicate-do-db=sales で起動され、ソースで次のステートメントを発行した場合、UPDATE ステートメントはレプリケートされません:

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

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

行ベースのレプリケーション.  レプリケーションをデータベース db_name に制限するようにレプリケーション SQL スレッドに指示します。 db_name に属するテーブルだけが変更されます。現在のデータベースはこれに影響しません。 レプリカが --replicate-do-db=sales で開始され、行ベースのレプリケーションが有効になっているとします。その後、次のステートメントがソースで実行されます:

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

レプリカ上の sales データベース内の february テーブルは、UPDATE ステートメントに従って変更されます。これは、USE ステートメントが発行されたかどうかに関係なく発生します。 ただし、行ベースのレプリケーションおよび --replicate-do-db=sales を使用している場合、ソースで次のステートメントを発行してもレプリカには影響しません:

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

ステートメント USE prices が USE sales に変更された場合でも、UPDATE ステートメントの結果は複製されません。

--replicate-do-db が行ベースレプリケーションとステートメントベースレプリケーションでどのように扱われるかについてもう 1 つ重要な違いは、複数のデータベースを参照するステートメントで発生します。 レプリカが --replicate-do-db=db1 で起動され、次のステートメントがソースで実行されるとします:

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

ステートメントベースレプリケーションを使用している場合は、両方のテーブルがレプリカで更新されます。 ただし、行ベースのレプリケーションを使用している場合、レプリカに対する影響を受けるのは table1 のみです。table2 は別のデータベースにあるため、レプリカ上の table2 は UPDATE によって変更されません。 ここで、USE db1 ステートメントの代わりに、USE db4 ステートメントが使用されたものとします。

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

この場合、ステートメントベースのレプリケーションを使用しても、UPDATE ステートメントはレプリカに影響しません。 ただし、行ベースのレプリケーションを使用している場合、UPDATE はレプリカ上の table1 を変更しますが、table2 は変更しません。つまり、--replicate-do-db によって指定されたデータベース内のテーブルのみが変更され、デフォルトデータベースの選択はこの動作に影響しません。

クロスデータベース更新を機能させる必要がある場合は、代わりに --replicate-wild-do-table=db_name.% を使用してください。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

--replicate-ignore-db=db_name

データベースの名前を使用してレプリケーションフィルタを作成します。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB を使用しても作成できます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-ignore-db:channel_1 :db_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

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

--replicate-do-db と同様に、このフィルタリングの正確な効果は、ステートメントベースと行ベースのどちらのレプリケーションが使用されているかによって異なり、次のいくつかの段落で説明します。

ステートメントベースのレプリケーション.  デフォルトデータベース (つまり、USE によって選択されたデータベース) が db_name であるステートメントをレプリケートしないようにレプリケーション SQL スレッドに指示します。

行ベースのレプリケーション.  データベース db_name 内のテーブルを更新しないようにレプリケーション SQL スレッドに指示します。 デフォルトデータベースは影響しません。

ステートメントベースレプリケーションを使用する場合、次の例は予期したとおりに機能しません。 レプリカが --replicate-ignore-db=sales で起動され、ソースで次のステートメントを発行するとします:

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

このような場合 UPDATE ステートメントは複製されます。--replicate-ignore-db が (USE ステートメントで指定された) デフォルトデータベースにのみ適用されるためです。 sales データベースがステートメントで明示的に指定されたため、ステートメントはフィルタされませんでした。 ただし、行ベースのレプリケーションを使用している場合、UPDATE ステートメントの効果はレプリカに伝播されず、sales.january テーブルのレプリカコピーは変更されません。この場合、--replicate-ignore-db=sales によって sales データベースのソースコピーのテーブルに対して行われた all の変更はレプリカによって無視されます。

クロスデータベース更新を使用していて、これらの更新を複製したくない場合は、このオプションを使用しないでください。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

クロスデータベース更新を機能させる必要がある場合、代わりに --replicate-wild-ignore-table=db_name.% を使用してください。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

--replicate-do-table=db_name.tbl_name

レプリケーションを特定のテーブルに制限するようにレプリケーション SQL スレッドに指示することで、レプリケーションフィルタを作成します。 複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 --replicate-do-db とは対照的に、これはクロスデータベース更新とデフォルトデータベース更新の両方に機能します。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_DO_TABLE ステートメントを発行して作成することもできます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-do-table:channel_1 :db_name.tbl_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

このオプションは、テーブルに適用されるステートメントにのみ影響します。 ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。 ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。

--replicate-ignore-table=db_name.tbl_name

同じステートメントによってほかのテーブルが更新される可能性がある場合でも、指定されたテーブルを更新するステートメントをレプリケートしないようにレプリケーション SQL スレッドに指示することによって、レプリケーションフィルタを作成します。 無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 --replicate-ignore-db とは対照的に、これはクロスデータベース更新に機能します。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE ステートメントを発行して作成することもできます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-ignore-table:channel_1 :db_name.tbl_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

このオプションは、テーブルに適用されるステートメントにのみ影響します。 ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。 ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。

--replicate-rewrite-db=from_name->to_name

指定されたデータベースがソース上の from_name である場合に、それを to_name に変換するレプリケーションフィルタを作成するようレプリカに指示します。 影響を受けるのはテーブルを含むステートメントのみで、CREATE DATABASE、DROP DATABASE、ALTER DATABASE などのステートメントは影響を受けません。

複数の書き換えを指定するには、複数回このオプションを使用します。 サーバーは、一致する from_name 値で最初のものを使用します。 データベース名変換は、--replicate-* ルールがテストされる前に行われます。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB ステートメントを発行して作成することもできます。

コマンドラインで --replicate-rewrite-db オプションを使用し、> 文字がコマンドインタプリタに特殊な場合は、オプション値を引用符で囲みます。 例:

shell> mysqld --replicate-rewrite-db="olddb->newdb"

--replicate-rewrite-db オプションの効果は、ステートメントベースと行ベースのどちらのバイナリロギング形式をクエリーに使用するかによって異なります。 ステートメントベースの形式では、DML ステートメントは、USE ステートメントで指定された現行のデータベースに基づいて変換されます。 行ベースの形式では、DML ステートメントは、変更されたテーブルが存在するデータベースに基づいて変換されます。 DDL ステートメントは、バイナリロギング形式に関係なく、常に USE ステートメントで指定された現在のデータベースに基づいてフィルタ処理されます。

リライトによって予期した結果が得られるようにするには、特に他のレプリケーションフィルタリングオプションと組み合せて、--replicate-rewrite-db オプションを使用する際に次の推奨事項に従います:

これらの推奨事項に従う場合は、--replicate-rewrite-db オプションを --replicate-do-table などのテーブルレベルのレプリケーションフィルタリングオプションと組み合せて使用しても安全です。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 チャネル名に続けてコロンを指定し、その後にフィルタ指定を指定します。 最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンとして解釈されます。 たとえば、channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、次を使用します:

shell> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2

コロンを使用してチャネル名を指定しない場合、このオプションはデフォルトのレプリケーションチャネルのレプリケーションフィルタを構成します。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

--replicate-same-server-id

このオプションはレプリカで使用します。 デフォルトは 0 (FALSE) です。 このオプションを 1 (TRUE) に設定すると、レプリカは独自のサーバー ID を持つイベントをスキップしません。 通常、この設定はまれな構成でのみ役立ちます。

レプリカでバイナリロギングが有効になっている場合、サーバーが循環レプリケーショントポロジの一部であると、レプリカ上の --replicate-same-server-id オプションと --log-slave-updates オプションの組み合わせによってレプリケーションで無限ループが発生する可能性があります。 (MySQL 8.0 では、バイナリロギングはデフォルトで有効になっており、バイナリロギングが有効になっている場合はレプリカ更新ロギングがデフォルトになります。) ただし、グローバルトランザクション識別子 (GTID) を使用すると、すでに適用されているトランザクションの実行がスキップされ、この状況が回避されます。 レプリカに gtid_mode=ON が設定されている場合、このオプションの組合せでサーバーを起動できますが、サーバーの実行中は他の GTID モードに変更できません。 ほかの GTID モードが設定されている場合、サーバーはこのオプションの組み合わせで起動しません。

デフォルトでは、複製サーバー ID を持っている場合、レプリケーション I/O スレッドはバイナリログイベントをリレーログに書き込みません (この最適化はディスク使用量の節約に役立ちます)。 --replicate-same-server-id を使用する場合は、レプリケーション SQL スレッドで実行する独自のイベントをレプリカで読み取る前に、必ずこのオプションを使用してレプリカを起動してください。

--replicate-wild-do-table=db_name.tbl_name

レプリケーション SQL スレッドに、更新されたテーブルのいずれかが指定されたデータベースおよびテーブル名パターンと一致するステートメントにレプリケーションを制限するように指示することで、レプリケーションフィルタを作成します。 パターンには、LIKE パターン一致演算子と同じ意味を持つ % および_ワイルドカード文字を含めることができます。 複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 これはクロスデータベース更新に役立ちます。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE ステートメントを発行して作成することもできます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-wild-do-table:channel_1 :db_name.tbl_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

このオプションはテーブル、ビュー、およびトリガーに適用されます。 ストアドプロシージャーと関数、またはイベントには適用されません。 後者のオブジェクトで作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。

たとえば、--replicate-wild-do-table=foo%.bar% は、データベース名が foo で始まり、テーブル名が bar で始まるテーブルを使用する更新のみをレプリケートします。

テーブル名パターンが % の場合、それは任意のテーブル名に一致し、このオプションはデータベースレベルステートメント (CREATE DATABASE、DROP DATABASE、および ALTER DATABASE) にも適用されます。 たとえば、--replicate-wild-do-table=foo%.% を使用する場合に、データベース名がパターン foo% に一致する場合はデータベースレベルステートメントが複製されます。

リテラルワイルドカード文字をデータベースまたはテーブル名パターンに含めるには、バックスラッシュでそれらをエスケープします。 たとえば、my_own%db という名前のデータベースのすべてのテーブルをレプリケートし、my1ownAABCdb データベースからはレプリケートしない場合は、次のように_および % 文字をエスケープする必要があります: --replicate-wild-do-table=my\_own\%db。 このオプションをコマンド行で使用する場合、コマンドインタープリターによっては、バックスラッシュを二重にしたりオプション値を引用符で囲んだりする必要があります。 たとえば、bash シェルでは、--replicate-wild-do-table=my\\_own\\%db と入力する必要があります。

--replicate-wild-ignore-table=db_name.tbl_name

レプリケーション SQL スレッドが、任意のテーブルが指定されたワイルドカードパターンと一致するステートメントをレプリケートしないようにするレプリケーションフィルタを作成します。 無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 これはクロスデータベース更新に役立ちます。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE ステートメントを発行して作成することもできます。

このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 channel_1 という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-wild-ignore:channel_1 :db_name.tbl_name を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。

たとえば、--replicate-wild-ignore-table=foo%.bar% では、データベース名が foo で始まり、テーブル名が bar で始まるテーブルを使用する更新はレプリケートされません。 照合の仕組みについては、--replicate-wild-do-table オプションの説明を参照してください。 オプション値にリテラルワイルドカード文字を含めるためのルールは、--replicate-wild-ignore-table 場合と同じです。

--skip-slave-start

サーバーの起動時にレプリケーション I/O および SQL スレッドを起動しないようにレプリカサーバーに指示します。 あとでスレッドを起動するには、START REPLICA | SLAVE ステートメントを使用します。

--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]

通常、レプリケーションはレプリカでエラーが発生すると停止するため、データの非一貫性を手動で解決できます。 このオプションを指定すると、ステートメントがオプション値にリストされているエラーのいずれかを返したときに、レプリケーション SQL スレッドはレプリケーションを続行します。

このオプションは、エラーが発生している理由を完全に理解しないかぎり使用しないでください。 レプリケーションセットアップとクライアントプログラムにバグがなく、MySQL 自体にバグがない場合は、レプリケーションを停止するエラーは発生しないはずです。 このオプションを使用しないと、レプリカがソースと同期しなくなりますが、これが発生した理由はわかりません。

エラーコードの場合は、レプリカエラーログおよび SHOW REPLICA | SLAVE STATUS の出力のエラーメッセージに示されている番号を使用する必要があります。付録B「エラーメッセージと一般的な問題」 には、サーバーエラーコードがリストされます。

短縮値 ddl_exist_errors は、エラーコードリスト 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146 と同等です。

また、all の推奨されない値を使用して、レプリカがすべてのエラーメッセージを無視し、何が発生したかに関係なく処理を続行するようにすることもできます (ただし、推奨されません)。 言うまでもなく、all を使用した場合、データの完全性に関して保証はありません。 この場合、レプリカデータがソース上のどこにも近い場所にない場合は、苦情 (またはバグレポートをファイル) しないでください。 以上のことを警告しました。

例:

--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors

--slave-sql-verify-checksum={0|1}

このオプションを有効にすると、レプリカはリレーログから読み取られたチェックサムを調べます。 不一致が発生した場合、レプリカはエラーで停止します。

--abort-slave-event-count

このオプションを 0 (デフォルト) 以外の正の整数 value に設定すると、次のようにレプリケーションの動作に影響: レプリケーション SQL スレッドが開始されると、value ログイベントの実行が許可されます。その後、レプリケーション SQL スレッドは、ソースからのネットワーク接続が切断された場合と同様に、これ以上イベントを受信しません。 レプリケーション SQL スレッドは引き続き実行され、SHOW REPLICA | SLAVE STATUS からの出力では、Replica_IO_Running と Replica_SQL_Running の両方のカラムに Yes が表示されますが、リレーログからそれ以上のイベントは読み取られません。

--disconnect-slave-event-count

init_slave

この変数は init_connect と似ていますが、レプリケーション SQL スレッドが開始されるたびにレプリカサーバーによって実行される文字列です。 文字列の形式は init_connect 変数の場合と同じです。 この変数の設定は、後続の START REPLICA | SLAVE ステートメントに対して有効になります。

log_slow_slave_statements

スロークエリーログが有効になっている場合、この変数は、レプリカでの実行に long_query_time 秒を超える時間がかかったクエリーのロギングを有効にします。 行ベースのレプリケーションが使用されている (binlog_format=ROW) 場合、log_slow_slave_statements は効果がないことに注意してください。 クエリーがレプリカのスロークエリーログに追加されるのは、バイナリログにステートメント形式で記録されている場合、つまり binlog_format=STATEMENT が設定されている場合、または binlog_format=MIXED が設定されていてステートメントがステートメント形式で記録されている場合だけです。 binlog_format=MIXED の設定時に行形式でログに記録されるスロークエリー、または binlog_format=ROW の設定時にログに記録されるスロークエリーは、log_slow_slave_statements が有効な場合でもレプリカのスロークエリーログに追加されません。

log_slow_slave_statements を設定しても、すぐには影響しません。 変数の状態は、後続のすべての START REPLICA | SLAVE ステートメントに適用されます。 また、long_query_time のグローバル設定は、SQL スレッドの存続期間中に適用されることに注意してください。 この設定を変更する場合は、レプリケーション SQL スレッドを停止して再起動し、そこで変更を実装する必要があります (たとえば、SQL_THREAD オプションを指定して STOP REPLICA | SLAVE および START REPLICA | SLAVE ステートメントを発行します)。

master_info_repository

このシステム変数の使用は非推奨になりました。 TABLE の設定がデフォルトであり、複数のレプリケーションチャネルが構成されている場合は必須です。 代替設定の FILE は、以前は非推奨でした。

デフォルト設定では、レプリカは、ステータスおよび接続情報で構成されるソースに関するメタデータを、mysql.slave_master_info という名前の mysql システムデータベースの InnoDB テーブルに記録します。 接続メタデータリポジトリの詳細は、セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照してください。

FILE 設定では、レプリカ接続メタデータリポジトリがファイルに書き込まれましたが、これはデフォルトで master.info という名前でした。 この名前は、--master-info-file オプションを使用して変更できます。

max_relay_log_size

レプリカによるリレーログへの書込みによって、現在のログファイルサイズがこの変数の値を超える場合、レプリカはリレーログをローテーションします (現在のファイルを閉じて次のファイルを開きます)。 max_relay_log_size が 0 の場合、サーバーはバイナリログとリレーログの両方に max_binlog_size を使用します。 max_relay_log_size が 0 より大きい場合、リレーログのサイズを抑制し、2 つのログに異なるサイズを持たせることが可能になります。 max_relay_log_size を 4096 バイトと 1G バイト (両端の値を含む) の間に設定するか、0 にする必要があります。 デフォルト値は 0 です。 セクション17.2.3「レプリケーションスレッド」を参照してください。

relay_log

リレーログファイルのベース名。 デフォルトのレプリケーションチャネルの場合、リレーログのデフォルトのベース名は host_name-relay-bin です。 デフォルト以外のレプリケーションチャネルの場合、リレーログのデフォルトのベース名は host_name-relay-bin-channel です。ここで、channel は、このリレーログに記録されているレプリケーションチャネルの名前です。

ベース名の先頭に絶対パス名を付けて別のディレクトリを指定しないかぎり、サーバーはファイルをデータディレクトリに書き込みます。 サーバーは、ベース名に数値の接尾辞を追加することによって、リレーログファイルを順番に作成します。

レプリケーションサーバーのリレーログおよびリレーログインデックスには、バイナリログおよびバイナリログインデックスと同じ名前を付けることはできません。バイナリログおよびバイナリログインデックスの名前は、--log-bin および --log-bin-index オプションで指定されます。 バイナリログとリレーログファイルのベース名が同じであれば、サーバーはエラーメッセージを発行し、起動しません。

MySQL がサーバーオプションを解析する方法のため、サーバーの起動時にこの変数を指定する場合は、デフォルトのベース名は、オプションが実際に指定されていない場合にのみ使用されますという値を指定する必要があります。 サーバーの起動時に値を指定せずに relay_log システム変数を指定すると、予期しない動作が発生する可能性があります。この動作は、使用される他のオプション、それらが指定されている順序、およびそれらがコマンド行とオプションファイルのどちらで指定されているかによって異なります。 MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.2「プログラムオプションの指定」を参照してください。

この変数を指定すると、指定した値がリレーログインデックスファイルのベース名としても使用されます。 この動作をオーバーライドするには、relay_log_index システム変数を使用して別のリレーログインデックスファイルのベース名を指定します。

サーバーは、インデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれているかどうかをチェックします。 その場合、パスの相対部分は、relay_log システム変数を使用して設定された絶対パスに置き換えられます。 絶対パスは変わりません。このような場合、使用される新しいパスを有効にするために、インデックスを手動で編集する必要があります。

relay_log システム変数は、次のタスクの実行に役立つ場合があります:

リレーログファイル名 (およびパス) は、relay_log_basename システム変数から取得できます。

relay_log_basename

リレーログファイルのベース名と完全パスを保持します。 最大可変長は 256 です。 この変数はサーバーによって設定され、読取り専用です。

relay_log_index

リレーログインデックスファイルの名前。 最大可変長は 256 です。 この変数を指定しないが、relay_log システム変数が指定されている場合、リレーログインデックスファイルのデフォルトのベース名としてその値が使用されます。 relay_log も指定されていない場合、デフォルトのレプリケーションチャネルのデフォルト名は、ホストマシンの名前を使用した host_name-relay-bin.index です。 デフォルト以外のレプリケーションチャネルの場合、デフォルト名は host_name-relay-bin-channel.index で、channel はこのリレーログインデックスに記録されているレプリケーションチャネルの名前です。

リレーログファイルのデフォルトの場所は、データディレクトリ、または relay_log システム変数を使用して指定されたその他の場所です。 ベース名に先頭の絶対パス名を追加して別のディレクトリを指定することで、relay_log_index システム変数を使用して別の場所を指定できます。

レプリケーションサーバーのリレーログおよびリレーログインデックスには、バイナリログおよびバイナリログインデックスと同じ名前を付けることはできません。バイナリログおよびバイナリログインデックスの名前は、--log-bin および --log-bin-index オプションで指定されます。 バイナリログとリレーログファイルのベース名が同じであれば、サーバーはエラーメッセージを発行し、起動しません。

MySQL がサーバーオプションを解析する方法のため、サーバーの起動時にこの変数を指定する場合は、デフォルトのベース名は、オプションが実際に指定されていない場合にのみ使用されますという値を指定する必要があります。 サーバーの起動時に値を指定せずに relay_log_index システム変数を指定すると、予期しない動作が発生する可能性があります。この動作は、使用される他のオプション、それらが指定されている順序、およびそれらがコマンド行とオプションファイルのどちらで指定されているかによって異なります。 MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.2「プログラムオプションの指定」を参照してください。

relay_log_info_file

このシステム変数の使用は非推奨になりました。 relay_log_info_repository=FILE が設定されている場合、レプリカアプライアンスメタデータリポジトリのファイル名を設定するために使用されていました。relay_log_info_file および relay_log_info_repository システム変数の使用は、アプライヤメタデータリポジトリのファイルの使用がクラッシュセーフテーブルに置き換えられたため、非推奨になりました。 適用者メタデータリポジトリの詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」 を参照してください。

relay_log_info_repository

このシステム変数の使用は非推奨になりました。 TABLE の設定がデフォルトであり、複数のレプリケーションチャネルが構成されている場合は必須です。 レプリカアプライアンスのメタデータリポジトリの TABLE 設定は、予期しない停止に対するレプリケーションの回復性を確保するためにも必要です。 詳しくはセクション17.4.2「レプリカの予期しない停止の処理」をご覧ください。 代替設定の FILE は、以前は非推奨でした。

デフォルト設定では、レプリカのアプライヤメタデータリポジトリは、mysql.slave_relay_log_info という名前の mysql システムデータベースに InnoDB テーブルとして格納されます。 適用者メタデータリポジトリの詳細は、セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照してください。

FILE 設定では、レプリカアプライアンスメタデータリポジトリがファイルに書き込まれましたが、これはデフォルトで relay-log.info という名前でした。 名前は、relay_log_info_file システム変数を使用して変更できます。

relay_log_purge

リレーログファイルが不要になったときに自動的にパージするよう無効または有効にします。 デフォルト値は 1 (ON) です。

relay_log_recovery

この変数を有効にすると、サーバーの起動直後にリレーログリカバリが自動的に有効になります。 リカバリプロセスでは、新しいリレーログファイルを作成し、SQL スレッド位置をこの新しいリレーログに初期化し、I/O スレッドを SQL スレッド位置に初期化します。 その後、ソースからのリレーログの読み取りが続行されます。

このグローバル変数は、実行時に読取り専用です。 この値は、レプリカサーバーの起動時に --relay-log-recovery オプションを使用して設定できます。このオプションは、破損する可能性のあるリレーログが処理されないようにするために、レプリカの予期しない停止後に使用する必要があり、クラッシュセーフなレプリカを保証するために使用する必要があります。 デフォルト値は 0 (無効)です。 予期しない停止に対して最も回復可能なレプリカの設定の組合せの詳細は、セクション17.4.2「レプリカの予期しない停止の処理」 を参照してください。

マルチスレッドレプリカ (slave_parallel_workers が 0 より大きい) の場合、起動時に --relay-log-recovery を設定すると、リレーログから実行された一連のトランザクションの不整合およびギャップが自動的に処理されます。 これらのギャップは、ファイル位置ベースのレプリケーションが使用されている場合に発生することがあります。 (詳細は、セクション17.5.1.34「レプリケーションとトランザクションの非一貫性」 を参照してください。) リレーログリカバリプロセスは、START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS ステートメントと同じ方法を使用してギャップを処理します。 レプリカが一貫性のないギャップのない状態に達すると、リレーログリカバリプロセスが進行し、SQL (適用者) スレッド位置からソースからさらにトランザクションがフェッチされます。 GTID ベースのレプリケーションが使用されている場合、このプロセスは不要であり、MASTER_AUTO_POSITION が ON に設定されている場合、MySQL 8.0.18 からマルチスレッドレプリカはリレーログのリカバリを自動的にスキップするため、relay_log_recovery の設定に違いはありません。

relay_log_space_limit

すべてのリレーログに使用するスペースの最大量。

replication_optimize_for_static_plugin_config

準同期レプリケーションのパフォーマンスを向上させるには、共有ロックを使用し、不要なロック取得を回避します。 このシステム変数が有効になっている間は準同期レプリケーションプラグインをアンインストールできないため、アンインストールを完了する前にシステム変数を無効にする必要があります。

このシステム変数は、準同期レプリケーションプラグインのインストール前またはインストール後に有効にしたり、レプリケーションの実行中に有効にしたりできます。 準同期レプリケーションソースサーバーも、複製と同じロックメカニズムを使用するため、このシステム変数を有効にすることでパフォーマンス上の利点を得ることができます。

replication_sender_observe_commit_only

準同期レプリケーションのパフォーマンスを向上させるには、コールバックを制限します。 このシステム変数は、準同期レプリケーションプラグインのインストール前またはインストール後に有効にしたり、レプリケーションの実行中に有効にしたりできます。 準同期レプリケーションソースサーバーも、複製と同じロックメカニズムを使用するため、このシステム変数を有効にすることでパフォーマンス上の利点を得ることができます。

report_host

レプリカの登録時にソースにレポートされるレプリカのホスト名または IP アドレス。 この値は、ソースサーバーの SHOW REPLICAS | SHOW SLAVE HOSTS の出力に表示されます。 レプリカ自体をソースに登録しない場合は、値を未設定のままにします。

report_password

レプリカの登録時にソースにレポートされるレプリカのアカウントパスワード。 この値は、ソースが --show-slave-auth-info で起動された場合に、ソースサーバー上の SHOW REPLICAS | SHOW SLAVE HOSTS の出力に表示されます。

この変数の名前は、それ以外の意味を持つ場合もありますが、report_password は MySQL ユーザー権限システムに接続されていないため、MySQL レプリケーションユーザーアカウントのパスワードと同じである必要はありません (または同じである可能性もあります)。

report_port

レプリカ登録時にソースにレポートされる、レプリカに接続するための TCP/IP ポート番号。 これは、レプリカがデフォルト以外のポートでリスニングしている場合、またはソースまたは他のクライアントからレプリカへの特別なトンネルがある場合にのみ設定します。 確実でない場合は、このオプションを使用しないでください。

このオプションのデフォルト値は、レプリカによって実際に使用されるポート番号です。 これは、SHOW REPLICAS | SHOW SLAVE HOSTS によって表示されるデフォルト値でもあります。

report_user

レプリカの登録時にソースにレポートされるレプリカのアカウントユーザー名。 この値は、ソースが --show-slave-auth-info で起動された場合に、ソースサーバー上の SHOW REPLICAS | SHOW SLAVE HOSTS の出力に表示されます。

この変数の名前はそれ以外を意味する場合もありますが、report_user は MySQL ユーザー権限システムに接続されていないため、必ずしも MySQL レプリケーションユーザーアカウントの名前と同じである必要はありません。

rpl_read_size

rpl_read_size システム変数は、バイナリログファイルおよびリレーログファイルから読み取られるデータの最小量をバイト単位で制御します。 これらのファイルに対する大量のディスク I/O アクティビティがデータベースのパフォーマンスを低下させている場合、ファイルデータがオペレーティングシステムによって現在キャッシュされていないと、読取りサイズを増やすとファイル読取りが減少し、I/O が停止する可能性があります。

rpl_read_size の最小値およびデフォルト値は 8192 バイトです。 値は 4KB の倍数である必要があります。 バイナリログおよびリレーログファイルから読み取るスレッドごとに、この値のバッファーが割り当てられます。これには、ソース上のダンプスレッドやレプリカ上のコーディネータスレッドも含まれます。 したがって、大きな値を設定すると、サーバーのメモリー消費に影響する可能性があります。

rpl_semi_sync_slave_enabled

レプリカサーバーで準同期レプリケーションを有効にするかどうかを制御します。 プラグインを有効または無効にするには、この変数を ON または OFF (あるいは 1 または 0) にそれぞれ設定します。 デフォルトは OFF です。

この変数は、レプリカ側の準同期レプリケーションプラグインがインストールされている場合にのみ使用できます。

rpl_semi_sync_slave_trace_level

レプリカサーバー上の準同期レプリケーションのデバッグトレースレベル。 許可できる値については、rpl_semi_sync_master_trace_level を参照してください。

この変数は、レプリカ側の準同期レプリケーションプラグインがインストールされている場合にのみ使用できます。

rpl_stop_slave_timeout

この変数を設定することで、STOP REPLICA | SLAVE がタイムアウトするまで待機する時間 (秒) を制御できます。 これを使用すると、レプリカへの異なるクライアント接続を使用する STOP REPLICA | SLAVE と他の SQL ステートメントの間のデッドロックを回避できます。

rpl_stop_slave_timeout の最大値およびデフォルト値は 31536000 秒 (1 年) です。 最小は 2 秒です。 この変数への変更は、後続の STOP REPLICA | SLAVE ステートメントに対して有効になります。

この変数は、STOP REPLICA | SLAVE ステートメントを発行するクライアントにのみ影響します。 タイムアウトに達すると、発行クライアントはコマンドの実行が不完全であることを示すエラーメッセージを返します。 その後、クライアントはレプリケーション I/O および SQL スレッドの停止の待機を停止しますが、レプリケーションスレッドは引き続き停止しようとし、STOP REPLICA | SLAVE 命令は有効なままです。 レプリケーションスレッドがビジー状態でなくなると、STOP REPLICA | SLAVE ステートメントが実行され、レプリカが停止します。

slave_checkpoint_group

SHOW REPLICA | SLAVE STATUS で示されているように、チェックポイント操作がコールされてステータスが更新されるまでにマルチスレッドレプリカで処理できるトランザクションの最大数を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべての START REPLICA | SLAVE コマンドに適用されます。

この変数は、slave_checkpoint_period システム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

この変数の最小許容値は 32 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、この場合の最小値は 1)。 効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。 (例外: このような丸めはデバッグサーバーでは実行されません。) サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。

slave_checkpoint_period

SHOW REPLICA | SLAVE STATUS で示されるように、マルチスレッドレプリカのステータスを更新するためにチェックポイント操作がコールされるまでに許容される最大時間 (ミリ秒) を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。

この変数は、slave_checkpoint_group システム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

この変数の最小許容値は 1 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、この場合の最小値は 0)。 サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。

slave_compressed_protocol

ソースとレプリカの両方でサポートされている場合に、ソース/レプリカ接続プロトコルの圧縮を使用するかどうか。 この変数が無効 (デフォルト) の場合、接続は圧縮解除されます。 この変数への変更は、後続の接続試行時に有効になります。これには、START REPLICA | SLAVE ステートメントの発行後、および実行中のレプリケーション I/O スレッドによって行われた再接続が含まれます。

binlog_transaction_compression システム変数によってアクティブ化されるバイナリログトランザクション圧縮 (MySQL 8.0.20 で使用可能) を使用して帯域幅を節約することもできます。 バイナリログトランザクション圧縮をプロトコル圧縮と組み合せて使用する場合、プロトコル圧縮ではデータを処理する機会は少なくなりますが、ヘッダーと、圧縮されていないイベントおよびトランザクションペイロードは圧縮できます。 バイナリログのトランザクション圧縮の詳細は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。

MySQL 8.0.18 の時点では、slave_compressed_protocol が有効な場合、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントに指定された SOURCE_COMPRESSION_ALGORITHMS | MASTER_COMPRESSION_ALGORITHMS オプションより優先されます。 この場合、ソースとレプリカの両方がそのアルゴリズムをサポートしていれば、ソースへの接続で zlib 圧縮が使用されます。 slave_compressed_protocol が無効な場合、SOURCE_COMPRESSION_ALGORITHMS | MASTER_COMPRESSION_ALGORITHMS の値が適用されます。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

MySQL 8.0.18 では、このシステム変数は非推奨です。 MySQL の将来のバージョンで削除される予定です。 レガシー接続圧縮の構成を参照してください。

slave_exec_mode

レプリケーション中にレプリケーションスレッドが競合およびエラーを解決する方法を制御します。 IDEMPOTENT モードでは、重複キーおよびキーが見つからないエラーが抑止されます。STRICT では、このような抑止は行われません。

IDEMPOTENT モードは、マルチソースレプリケーション、循環レプリケーション、および NDB Cluster レプリケーションのその他の特殊なレプリケーションシナリオで使用することを目的としています。 (詳しくは、セクション23.6.10「NDB Cluster レプリケーション: 双方向および循環レプリケーション」およびセクション23.6.11「NDB Cluster レプリケーションの競合解決」を参照してください。) NDB Cluster は、slave_exec_mode に明示的に設定された値を無視し、常に IDEMPOTENT として扱います。

MySQL Server 8.0 では、STRICT モードがデフォルト値です。

この変数を設定すると、実行中のチャネルを含むすべてのレプリケーションチャネルに対して即時に有効になります。

NDB、「IDEMPOTENT モードは、重複キーエラーおよびキーが見つからないエラーが無視される可能性があることを絶対に確認している場合にのみ使用してください」以外のストレージエンジンの場合。 マルチソースレプリケーションまたは循環レプリケーションが採用されている NDB Cluster のフェイルオーバーシナリオで使用されることを意図しており、ほかの場合には使用しないことをお勧めします。

slave_load_tmpdir

レプリカが一時ファイルを作成するディレクトリの名前。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。 変数値は、デフォルトでは tmpdir システム変数の値、またはそのシステム変数が指定されていない場合に適用されるデフォルトと等しくなります。

レプリケーション SQL スレッドは、LOAD DATA ステートメントをレプリケートするときに、リレーログから一時ファイルにロードされるファイルを抽出し、それらをテーブルにロードします。 ソースにロードされたファイルが膨大な場合、レプリカ上の一時ファイルも膨大になります。 したがって、このオプションを使用して、使用可能な領域が大量にある一部のファイルシステムにあるディレクトリに一時ファイルを配置するようレプリカに指示することをお薦めします。 その場合、リレーログも非常に大きいため、リレーログをそのファイルシステムに配置するように relay_log システム変数を設定することもできます。

このオプションで指定するディレクトリは、LOAD DATA ステートメントのレプリケートに使用される一時ファイルがマシンの再起動後も存続できるように、メモリーベースのファイルシステムではなくディスクベースのファイルシステムに配置する必要があります。 このディレクトリは、システム起動プロセス中にオペレーティングシステムによってクリアされるものではいけません。 ただし、一時ファイルが削除されている場合は、再起動後にレプリケーションを続行できるようになりました。

slave_max_allowed_packet

このオプションは、レプリケーション SQL および I/O スレッドが処理できる最大パケットサイズをバイト単位で設定します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。 イベントヘッダーが追加されると、ソースは max_allowed_packet 設定より長いバイナリログイベントを書き込むことができます。 slave_max_allowed_packet の設定は、行ベースのレプリケーションを使用した大規模な更新によってレプリケーションが失敗しないように、ソースの max_allowed_packet 設定より大きくする必要があります。

このグローバル変数は常に、1024 の正の整数の倍数である値を持ちます。そうでない何らかの値に設定しても、値は次に大きい 1024 の倍数に自動的に丸められて、格納または使用されます。slave_max_allowed_packet を 0 に設定すると、1024 が使用されます。 (このような場合、切り捨ての警告が発行されます。) デフォルトおよび最大値は 1073741824 (1G バイト) で、最小は 1024 です。

slave_net_timeout

レプリカが接続の切断を考慮し、読取りを中断して再接続を試行するまでに、ソースからさらにデータまたはハートビートシグナルを待機する秒数。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべての START REPLICA | SLAVE コマンドに適用されます。

デフォルト値は 60 秒 (1 分) です。 最初の再試行はタイムアウトの直後に発生します。 再試行の間隔は、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_CONNECT_RETRY | MASTER_CONNECT_RETRY オプションによって制御され、再接続の試行回数は SOURCE_RETRY_COUNT | MASTER_RETRY_COUNT オプションによって制限されます。

ハートビート間隔は、データが存在しない場合に接続タイムアウトが発生するのを停止します (接続が正常な場合)。ハートビート間隔は、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_HEARTBEAT_PERIOD | MASTER_HEARTBEAT_PERIOD オプションによって制御されます。 ハートビート間隔はデフォルトで slave_net_timeout の半分の値に設定され、レプリカ接続メタデータリポジトリに記録されて replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。 slave_net_timeout の値またはデフォルト設定を変更しても、明示的に設定されているか、以前に計算されたデフォルトを使用しているかにかかわらず、ハートビート間隔は自動的には変更されないことに注意してください。 接続タイムアウトが変更された場合は、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO も発行して、接続タイムアウトの前に発生するようにハートビート間隔を適切な値に調整する必要があります。

slave_parallel_type

マルチスレッドのレプリカ (slave_parallel_workers が 0 より大きい値に設定されているレプリカ) の場合、slave_parallel_type はレプリカでパラレルに実行できるトランザクションを決定するために使用されるポリシーを指定します。 この変数は、マルチスレッドが有効になっていないレプリカには影響しません。 指定可能な値は次のとおりです。

slave_preserve_commit_order=1 が設定されている場合、使用できるのは LOGICAL_CLOCK のみです。

レプリケーショントポロジで複数レベルのレプリカが使用されている場合、LOGICAL_CLOCK ではレプリカがソースから離れている各レベルのパラレル化が実現されないことがあります。 可能な場合は、ソースで binlog_transaction_dependency_tracking を使用してパラレル化にタイムスタンプのかわりに書込みセットを使用するように指定することで、この影響を軽減できます。

binlog_transaction_compression システム変数を使用してバイナリログトランザクション圧縮が有効になっている場合、slave_parallel_type が DATABASE に設定されていると、トランザクションがスケジュールされる前に、トランザクションの影響を受けるすべてのデータベースがマップされます。 バイナリログトランザクション圧縮を DATABASE ポリシーとともに使用すると、イベントごとにマップおよびスケジュールされる圧縮されていないトランザクションと比較して並列度を減らすことができます。

slave_parallel_workers

レプリカでマルチスレッドを有効にし、レプリケーショントランザクションをパラレルに実行するためのアプライヤスレッドの数を設定します。 値が 0 より大きい場合、レプリカは、指定された数のアプライヤスレッドと、それらを管理するためのコーディネータスレッドを持つマルチスレッドのレプリカです。 複数のレプリケーションチャネルを使用している場合、各チャネルにはこの数のスレッドがあります。

レプリカでマルチスレッドが有効になっている場合、トランザクションの再試行がサポートされます。 slave_preserve_commit_order=1 の場合 レプリカ上のトランザクションは、レプリカリレーログに表示される順序と同じ順序でレプリカ上で外部化されます。 トランザクションがアプライヤスレッド間で分散される方法は、slave_parallel_type によって構成されます。

パラレル実行を無効にするには、このオプションを 0 に設定します。これにより、レプリカに単一のアプライヤスレッドが提供され、コーディネータスレッドは提供されません。 この設定では、slave_parallel_type および slave_preserve_commit_order システム変数は効果がなく、無視されます。

slave_parallel_workers を設定しても、すぐには影響しません。 変数の状態は、後続のすべての START REPLICA | SLAVE ステートメントに適用されます。

slave_pending_jobs_size_max

マルチスレッドレプリカの場合、この変数は、まだ適用されていないイベントを保持するアプライヤキューで使用可能なメモリーの最大量 (バイト単位) を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべての START REPLICA | SLAVE コマンドに適用されます。

この変数に指定できる最小値は 1024 バイトです。デフォルトは 128MB です。 可能な最大値は 18446744073709551615 (16 exbibytes) です。 1024 バイトの正確な倍数でない値は、格納される前に 1024 バイトの次の小さい倍数に切り捨てられます。

この変数の値は弱い制限であり、通常のワークロードと一致するように設定できます。 異常に大きいイベントがこのサイズを超えると、すべてのワーカースレッドに空のキューが設定されてから処理されるまで、トランザクションは保持されます。 後続のすべてのトランザクションは、大規模なトランザクションが完了するまで保持されます。

slave_preserve_commit_order

マルチスレッドのレプリカ (slave_parallel_workers が 0 より大きい値に設定されているレプリカ) の場合、slave_preserve_commit_order=1 を設定すると、トランザクションはレプリカリレーログと同じ順序でレプリカで実行およびコミットされます。 これにより、レプリカリレーログから実行された一連のトランザクションのギャップが回避され、レプリカとソースで同じトランザクション履歴が保持されます (ただし、次の制限があります)。 この変数は、マルチスレッドが有効になっていないレプリカには影響しません。

MySQL 8.0.18 まで、slave_preserve_commit_order=1 を設定するには、バイナリロギング (log_bin) およびレプリカ更新ロギング (log_slave_updates) がレプリカで有効になっている必要があります。これは、MySQL 8.0 のデフォルト設定です。 MySQL 8.0.19 からは、バイナリロギングおよびレプリカ更新ロギングは、slave_preserve_commit_order=1 を設定するためにレプリカでは必要なく、必要に応じて無効にできます。 すべてのリリースで、slave_preserve_commit_order=1 を設定するには、slave_parallel_type がデフォルト設定ではない LOGICAL_CLOCK に設定されている必要があります。 slave_preserve_commit_order および slave_parallel_type の値を変更する前に、レプリケーション SQL スレッド (複数のレプリケーションチャネルを使用している場合はすべてのレプリケーションチャネル用) を停止する必要があります。

slave_preserve_commit_order=0 が設定されている場合 (デフォルト)、マルチスレッドレプリカがパラレルで適用するトランザクションは、順序が正しくない場合があります。 したがって、最後に実行されたトランザクションのチェックでは、ソースの以前のすべてのトランザクションがレプリカで実行されていることは保証されません。 レプリカリレーログから実行された一連のトランザクションにギャップが生じる可能性があります。 これは、マルチスレッドレプリカを使用する場合のロギングおよびリカバリに影響します。 詳しくはセクション17.5.1.34「レプリケーションとトランザクションの非一貫性」をご覧ください。

slave_preserve_commit_order=1 が設定されている場合、実行中のワーカースレッドは、前のすべてのトランザクションがコミットされるまで待機してからコミットします。 特定のスレッドが他のワーカースレッドによるトランザクションのコミットを待機している間、そのステータスは Waiting for preceding transaction to commit としてレポートされます。 このモードでは、マルチスレッドレプリカはソースが存在しなかった状態になることはありません。 これにより、読取りスケールアウトでのレプリケーションの使用がサポートされます。 セクション17.4.5「スケールアウトのためにレプリケーションを使用する」を参照してください。

slave_rows_search_algorithms

行ベースのロギングおよびレプリケーションのために行のバッチを準備する場合、このシステム変数は、行で一致を検索する方法、特にハッシュスキャンを使用するかどうかを制御します。 このシステム変数の使用は非推奨になりました。 デフォルト設定の INDEX_SCAN,HASH_SCAN はパフォーマンスに最適で、すべてのシナリオで正しく機能します。 セクション17.5.1.27「レプリケーションおよび行検索」を参照してください。

slave_skip_errors

通常、レプリケーションはレプリカでエラーが発生すると停止するため、データの非一貫性を手動で解決できます。 この変数を指定すると、ステートメントが変数値にリストされているエラーのいずれかを返したときに、レプリケーション SQL スレッドはレプリケーションを続行します。

slave_sql_verify_checksum

レプリケーション SQL スレッドがリレーログから読み取られたチェックサムを使用してデータを検証するようにします。 不一致が発生した場合、レプリカはエラーで停止します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。

slave_transaction_retries

シングルスレッドまたはマルチスレッドレプリカ上のレプリケーション SQL スレッドが、停止前に失敗したトランザクションを自動的に再試行する最大回数を設定します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。 デフォルト値は 10 です。 変数を 0 に設定すると、トランザクションの自動再試行が無効になります。

InnoDB デッドロックのため、またはトランザクション実行時間が InnoDB の innodb_lock_wait_timeout、NDB の TransactionDeadlockDetectionTimeout または TransactionInactiveTimeout を超えたためにレプリケーション SQL スレッドがトランザクションの実行に失敗した場合、エラーで停止する前に slave_transaction_retries 回自動的に再試行されます。 一時的でないエラーのあるトランザクションは再試行されません。

「パフォーマンススキーマ」テーブル replication_applier_status の COUNT_TRANSACTIONS_RETRIES カラムには、各レプリケーションチャネルで行われた再試行回数が表示されます。 「パフォーマンススキーマ」テーブル replication_applier_status_by_worker には、シングルスレッドまたはマルチスレッドレプリカ上の個々のアプライヤスレッドによるトランザクションの再試行に関する詳細情報が表示され、最後のトランザクションの原因となったエラーおよび現在進行中のトランザクションの再試行が識別されます。

slave_type_conversions

行ベースレプリケーションの使用時にレプリカで有効な型変換モードを制御します。 その値は、リスト内のゼロ個以上の要素のカンマ区切りセットです: ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED。 ソースとレプリカ間の型変換を禁止するには、この変数を空の文字列に設定します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。

行ベースレプリケーションで属性の昇格と降格に適用できるタイプ変換モードの詳細については、行ベースレプリケーション: 属性の昇格と降格を参照してください。

sql_slave_skip_counter

レプリカがスキップするソースからのイベントの数。 このオプションを設定しても、すぐには影響しません。 変数は次の START REPLICA | SLAVE ステートメントに適用され、次の START REPLICA | SLAVE ステートメントでも値が 0 に戻ります。 この変数がゼロ以外の値に設定され、複数のレプリケーションチャネルが構成されている場合、START REPLICA | SLAVE ステートメントは FOR CHANNEL channel 句でのみ使用できます。

このオプションは GTID ベースのレプリケーションと互換性がなく、gtid_mode=ON が設定されている場合はゼロ以外の値に設定しないでください。 GTID の採用時にトランザクションをスキップする必要がある場合は、かわりにソースから gtid_executed を使用します。 CHANGE REPLICATION SOURCE TO ステートメントの ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションを使用してレプリケーションチャネルで GTID 割当てを有効にした場合、sql_slave_skip_counter を使用できます。 セクション17.1.7.3「トランザクションのスキップ」を参照してください。

sync_master_info

レプリカが接続メタデータリポジトリを更新するまでのイベント数。 接続メタデータリポジトリが MySQL 8.0 のデフォルトである InnoDB テーブルとして格納されている場合、この数のイベントの後に更新されます。 接続メタデータリポジトリが、MySQL 8.0 から非推奨になったファイルとして格納されている場合、レプリカは、この数のイベントの後に、(fdatasync() を使用して) master.info ファイルをディスクに同期します。 デフォルト値は 10000 で、ゼロ値はリポジトリが更新されないことを意味します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。

sync_relay_log

この変数の値が 0 より大きい場合は、すべての sync_relay_log イベントがリレーログに書き込まれたあとに、MySQL サーバーはそのリレーログをディスクに同期します (fdatasync() を使用)。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。

sync_relay_log を 0 に設定すると、ディスクへの同期は実行されません。この場合、サーバーはオペレーティングシステムに依存してほかのファイルに関してリレーログの内容をときどきフラッシュします。

値 1 は、予期しない停止が発生した場合にリレーログから最大 1 つのイベントが失われるため、もっとも安全な選択です。 しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。 予期しない停止に対して最も回復可能なレプリカの設定の組合せの詳細は、セクション17.4.2「レプリカの予期しない停止の処理」 を参照してください。

sync_relay_log_info

レプリカが適用者メタデータリポジトリを更新するまでのトランザクションの数。 アプライヤメタデータリポジトリが MySQL 8.0 のデフォルトである InnoDB テーブルとして格納されている場合、トランザクションのたびに更新され、このシステム変数は無視されます。 アプライヤメタデータリポジトリが、MySQL 8.0 で非推奨になったファイルとして格納されている場合、レプリカは、この数のトランザクションの後に、(fdatasync() を使用して) relay-log.info ファイルをディスクに同期します。 sync_relay_log_info のデフォルト値は 10000 で、ゼロ値はファイルの内容がオペレーティングシステムによってのみフラッシュされることを意味します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。