PDF (US Ltr)
- 36.1Mb
PDF (A4)
- 36.2Mb
このページは機械翻訳したものです。
このセクションでは、レプリカサーバーに適用されるサーバーオプションおよびシステム変数について説明します。このセクションの内容は次のとおりです:
オプションはコマンド行またはオプションファイルで指定します。 サーバーの実行中に、(MySQL 8.0.23 の) CHANGE REPLICATION SOURCE TO ステートメントまたは (MySQL 8.0.23 の前の) CHANGE MASTER TO ステートメントを使用して、多くのオプションを設定できます。 システム変数値は SET を使用して指定します。
サーバー ID.
ソースおよび各レプリカで、server_id システム変数を設定して、1 から 2 32− 1 の範囲の一意のレプリケーション ID を確立する必要があります。 「Unique」 は、各 ID がレプリケーショントポロジ内の他のソースまたはレプリカで使用されている他のすべての ID と異なる必要があることを意味します。 my.cnf ファイルの例:
[mysqld]
server-id=3
このセクションでは、レプリカサーバーを制御するための起動オプションについて説明します。 これらのオプションの多くは、(MySQL 8.0.23 の) CHANGE REPLICATION SOURCE TO ステートメントまたは (MySQL 8.0.23 の前の) CHANGE MASTER TO ステートメントを使用して、サーバーの実行中に設定できます。 その他のオプション (--replicate-* オプションなど) は、レプリカサーバーの起動時にのみ設定できます。 レプリケーションに関連するシステム変数はこのセクションの後半で説明します。
-
コマンド行形式 --master-info-file=file_name非推奨 8.0.18 型 ファイル名 デフォルト値 master.infoこのオプションの使用は非推奨になりました。
master_info_repository=FILEが設定されている場合は、レプリカ接続メタデータリポジトリのファイル名を設定するために使用されていました。接続メタデータリポジトリのファイルの使用がクラッシュセーフテーブルに置き換えられたため、--master-info-fileおよびmaster_info_repositoryシステム変数の使用は非推奨になりました。 接続メタデータリポジトリの詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」 を参照してください。 -
コマンド行形式 --master-retry-count=#非推奨 はい 型 Integer デフォルト値 86400最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295レプリカがソースへの再接続を試行してから中止する回数。 デフォルト値は 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=#システム変数 max_relay_log_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 1073741824このサイズで、サーバーはリレーログファイルを自動的にローテーションします。 この値がゼロでない場合は、サイズがこの値を超えたときにリレーログは自動的にローテーションされます。 この値がゼロ (デフォルト) の場合、リレーログローテーションが発生するサイズは
max_binlog_sizeの値によって決められます。 詳細は、セクション17.2.4.1「リレーログ」を参照してください。 -
コマンド行形式 --relay-log-purge[={OFF|ON}]システム変数 relay_log_purgeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONリレーログファイルが不要になるとすぐに自動的にパージすることを無効または有効にします。 デフォルト値は 1 (有効)です。 これは
SET GLOBAL relay_log_purge =で動的に変更できるグローバル変数です。N--relay-log-recoveryオプションを有効にするときにリレーログのパージを無効にすると、データの整合性が損なわれるため、クラッシュセーフではありません。 -
コマンド行形式 --relay-log-space-limit=#システム変数 relay_log_space_limitスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295このオプションは、レプリカ上のすべてのリレーログの合計サイズの上限をバイト単位で設定します。 値 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=name型 文字列 データベースの名前を使用してレプリケーションフィルタを作成します。 このようなフィルタは、
CHANGE REPLICATION FILTER REPLICATE_DO_DBを使用しても作成できます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-do-db:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。このレプリケーションフィルタの正確な効果は、ステートメントベースレプリケーションと行ベースレプリケーションのどちらが使用されているかによって異なります。
ステートメントベースのレプリケーション. レプリケーション SQL スレッドに、デフォルトデータベース (つまり、
USEによって選択されたデータベース) がdb_nameであるステートメントにレプリケーションを制限するように指示します。 複数のデータベースを指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。ただし、このようにすると別のデータベースは選択される (またはデータベースが選択されない) けれども、UPDATEなどのクロスデータベースステートメントを複製しません。some_db.some_tableSET 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=を使用してください。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。db_name.%注記このオプションは、
--binlog-do-dbがバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-do-dbがレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-do-db動作に対してロギング形式がどのように影響するかと同じです。このオプションは、
BEGIN、COMMIT、またはROLLBACKステートメントに影響しません。 -
コマンド行形式 --replicate-ignore-db=name型 文字列 データベースの名前を使用してレプリケーションフィルタを作成します。 このようなフィルタは、
CHANGE REPLICATION FILTER REPLICATE_IGNORE_DBを使用しても作成できます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-ignore-db:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。無視するデータベースを複数指定するには、このオプションを複数回 (データベースごとに 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=を使用してください。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。db_name.%注記このオプションは、
--binlog-ignore-dbがバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-ignore-dbがレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-ignore-db動作に対してロギング形式がどのように影響するかと同じです。このオプションは、
BEGIN、COMMIT、またはROLLBACKステートメントに影響しません。 -
--replicate-do-table=db_name.tbl_nameコマンド行形式 --replicate-do-table=name型 文字列 レプリケーションを特定のテーブルに制限するようにレプリケーション SQL スレッドに指示することで、レプリケーションフィルタを作成します。 複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。
--replicate-do-dbとは対照的に、これはクロスデータベース更新とデフォルトデータベース更新の両方に機能します。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_DO_TABLEステートメントを発行して作成することもできます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-do-table:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name.tbl_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。このオプションは、テーブルに適用されるステートメントにのみ影響します。 ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。 ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の
--replicate-*-dbオプションを使用します。 -
--replicate-ignore-table=db_name.tbl_nameコマンド行形式 --replicate-ignore-table=name型 文字列 同じステートメントによってほかのテーブルが更新される可能性がある場合でも、指定されたテーブルを更新するステートメントをレプリケートしないようにレプリケーション SQL スレッドに指示することによって、レプリケーションフィルタを作成します。 無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。
--replicate-ignore-dbとは対照的に、これはクロスデータベース更新に機能します。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLEステートメントを発行して作成することもできます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-ignore-table:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name.tbl_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。このオプションは、テーブルに適用されるステートメントにのみ影響します。 ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。 ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の
--replicate-*-dbオプションを使用します。 -
--replicate-rewrite-db=from_name->to_nameコマンド行形式 --replicate-rewrite-db=old_name->new_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オプションを使用する際に次の推奨事項に従います:ソースおよびレプリカに異なる名前で
from_nameおよびto_nameデータベースを手動で作成します。ステートメントベースまたは混合バイナリロギング形式を使用する場合は、クロスデータベースクエリーを使用せず、クエリーでデータベース名を指定しないでください。 DDL ステートメントと DML ステートメントの両方で、
USEステートメントを使用して現在のデータベースを指定し、クエリーでテーブル名のみを使用します。DDL ステートメントで行ベースのバイナリロギング形式を排他的に使用する場合は、
USEステートメントを使用して現在のデータベースを指定し、クエリーでテーブル名のみを使用します。 DML ステートメントには、完全修飾テーブル名 (db) を使用できます。table) (必要な場合)。
これらの推奨事項に従う場合は、
--replicate-rewrite-dbオプションを--replicate-do-tableなどのテーブルレベルのレプリケーションフィルタリングオプションと組み合せて使用しても安全です。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。 チャネル名に続けてコロンを指定し、その後にフィルタ指定を指定します。 最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンとして解釈されます。 たとえば、
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、次を使用します:shell> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2コロンを使用してチャネル名を指定しない場合、このオプションはデフォルトのレプリケーションチャネルのレプリケーションフィルタを構成します。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。
注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。 -
コマンド行形式 --replicate-same-server-id[={OFF|ON}]型 Boolean デフォルト値 OFFこのオプションはレプリカで使用します。 デフォルトは 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コマンド行形式 --replicate-wild-do-table=name型 文字列 レプリケーション SQL スレッドに、更新されたテーブルのいずれかが指定されたデータベースおよびテーブル名パターンと一致するステートメントにレプリケーションを制限するように指示することで、レプリケーションフィルタを作成します。 パターンには、
LIKEパターン一致演算子と同じ意味を持つ%および_ワイルドカード文字を含めることができます。 複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 これはクロスデータベース更新に役立ちます。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLEステートメントを発行して作成することもできます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-wild-do-table:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name.tbl_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。このオプションはテーブル、ビュー、およびトリガーに適用されます。 ストアドプロシージャーと関数、またはイベントには適用されません。 後者のオブジェクトで作用するステートメントをフィルタするには、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コマンド行形式 --replicate-wild-ignore-table=name型 文字列 レプリケーション SQL スレッドが、任意のテーブルが指定されたワイルドカードパターンと一致するステートメントをレプリケートしないようにするレプリケーションフィルタを作成します。 無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。 これはクロスデータベース更新に役立ちます。 セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。 このようなフィルタは、
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLEステートメントを発行して作成することもできます。このオプションでは、チャネル固有のレプリケーションフィルタがサポートされているため、マルチソースレプリカは異なるソースに対して特定のフィルタを使用できます。
channel_1という名前のチャネルでチャネル固有のレプリケーションフィルタを構成するには、--replicate-wild-ignore:を使用します。 この場合、最初のコロンはセパレータとして解釈され、後続のコロンはリテラルコロンです。 詳しくはセクション17.2.5.4「レプリケーションチャネルベースのフィルタ」をご覧ください。channel_1:db_name.tbl_name注記グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。たとえば、
--replicate-wild-ignore-table=foo%.bar%では、データベース名がfooで始まり、テーブル名がbarで始まるテーブルを使用する更新はレプリケートされません。 照合の仕組みについては、--replicate-wild-do-tableオプションの説明を参照してください。 オプション値にリテラルワイルドカード文字を含めるためのルールは、--replicate-wild-ignore-table場合と同じです。 -
コマンド行形式 --skip-slave-start[={OFF|ON}]型 Boolean デフォルト値 OFFサーバーの起動時にレプリケーション I/O および SQL スレッドを起動しないようにレプリカサーバーに指示します。 あとでスレッドを起動するには、
START REPLICA | SLAVEステートメントを使用します。 -
--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]コマンド行形式 --slave-skip-errors=nameシステム変数 slave_skip_errorsスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 文字列 デフォルト値 OFF有効な値 OFF[list of error codes]allddl_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}コマンド行形式 --slave-sql-verify-checksum[={OFF|ON}]型 Boolean デフォルト値 ONこのオプションを有効にすると、レプリカはリレーログから読み取られたチェックサムを調べます。 不一致が発生した場合、レプリカはエラーで停止します。
次のオプションは、レプリケーションテストおよびデバッグのために MySQL テストスイートによって内部的に使用されます。 本番設定での使用は意図していません。
-
コマンド行形式 --abort-slave-event-count=#型 Integer デフォルト値 0最小値 0このオプションを 0 (デフォルト) 以外の正の整数
valueに設定すると、次のようにレプリケーションの動作に影響: レプリケーション SQL スレッドが開始されると、valueログイベントの実行が許可されます。その後、レプリケーション SQL スレッドは、ソースからのネットワーク接続が切断された場合と同様に、これ以上イベントを受信しません。 レプリケーション SQL スレッドは引き続き実行され、SHOW REPLICA | SLAVE STATUSからの出力では、Replica_IO_RunningとReplica_SQL_Runningの両方のカラムにYesが表示されますが、リレーログからそれ以上のイベントは読み取られません。 -
--disconnect-slave-event-countコマンド行形式 --disconnect-slave-event-count=#型 Integer デフォルト値 0
次のリストでは、レプリカサーバーを制御するためのシステム変数について説明します。 これらはサーバー起動時に設定でき、それらの一部は SET を使用して実行時に変更できます。 レプリカで使用されるサーバーオプションは、このセクションで前述しました。
-
コマンド行形式 --init-slave=nameシステム変数 init_slaveスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 文字列 この変数は
init_connectと似ていますが、レプリケーション SQL スレッドが開始されるたびにレプリカサーバーによって実行される文字列です。 文字列の形式はinit_connect変数の場合と同じです。 この変数の設定は、後続のSTART REPLICA | SLAVEステートメントに対して有効になります。注記レプリケーション SQL スレッドは、
init_slaveを実行する前にクライアントに確認を送信します。 したがって、START REPLICA | SLAVEが戻ったときにinit_slaveが実行されていることは保証されていません。 詳しくはセクション13.4.2.7「START REPLICA | SLAVE ステートメント」をご覧ください。 -
コマンド行形式 --log-slow-slave-statements[={OFF|ON}]システム変数 log_slow_slave_statementsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFスロークエリーログが有効になっている場合、この変数は、レプリカでの実行に
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={FILE|TABLE}非推奨 8.0.23 システム変数 master_info_repositoryスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 文字列 デフォルト値 TABLE有効な値 FILETABLEこのシステム変数の使用は非推奨になりました。
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スコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 1073741824レプリカによるリレーログへの書込みによって、現在のログファイルサイズがこの変数の値を超える場合、レプリカはリレーログをローテーションします (現在のファイルを閉じて次のファイルを開きます)。
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=file_nameシステム変数 relay_logスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 リレーログファイルのベース名。 デフォルトのレプリケーションチャネルの場合、リレーログのデフォルトのベース名は
host_name-relay-binhost_name-relay-bin-channelchannelは、このリレーログに記録されているレプリケーションチャネルの名前です。ベース名の先頭に絶対パス名を付けて別のディレクトリを指定しないかぎり、サーバーはファイルをデータディレクトリに書き込みます。 サーバーは、ベース名に数値の接尾辞を追加することによって、リレーログファイルを順番に作成します。
レプリケーションサーバーのリレーログおよびリレーログインデックスには、バイナリログおよびバイナリログインデックスと同じ名前を付けることはできません。バイナリログおよびバイナリログインデックスの名前は、
--log-binおよび--log-bin-indexオプションで指定されます。 バイナリログとリレーログファイルのベース名が同じであれば、サーバーはエラーメッセージを発行し、起動しません。MySQL がサーバーオプションを解析する方法のため、サーバーの起動時にこの変数を指定する場合は、デフォルトのベース名は、オプションが実際に指定されていない場合にのみ使用されますという値を指定する必要があります。 サーバーの起動時に値を指定せずに
relay_logシステム変数を指定すると、予期しない動作が発生する可能性があります。この動作は、使用される他のオプション、それらが指定されている順序、およびそれらがコマンド行とオプションファイルのどちらで指定されているかによって異なります。 MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.2「プログラムオプションの指定」を参照してください。この変数を指定すると、指定した値がリレーログインデックスファイルのベース名としても使用されます。 この動作をオーバーライドするには、
relay_log_indexシステム変数を使用して別のリレーログインデックスファイルのベース名を指定します。サーバーは、インデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれているかどうかをチェックします。 その場合、パスの相対部分は、
relay_logシステム変数を使用して設定された絶対パスに置き換えられます。 絶対パスは変わりません。このような場合、使用される新しいパスを有効にするために、インデックスを手動で編集する必要があります。relay_logシステム変数は、次のタスクの実行に役立つ場合があります:名前がホスト名に依存しないリレーログを作成する。
リレーログが非常に大きくなる傾向があり、
max_relay_log_sizeを小さくしたくないため、リレーログをデータディレクトリ以外の領域に置く必要がある場合。ディスク間のロードバランシングを使用して速度を上げるため。
リレーログファイル名 (およびパス) は、
relay_log_basenameシステム変数から取得できます。 -
システム変数 relay_log_basenameスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 デフォルト値 datadir + '/' + hostname + '-relay-bin'リレーログファイルのベース名と完全パスを保持します。 最大可変長は 256 です。 この変数はサーバーによって設定され、読取り専用です。
-
コマンド行形式 --relay-log-index=file_nameシステム変数 relay_log_indexスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 デフォルト値 *host_name*-relay-bin.indexリレーログインデックスファイルの名前。 最大可変長は 256 です。 この変数を指定しないが、
relay_logシステム変数が指定されている場合、リレーログインデックスファイルのデフォルトのベース名としてその値が使用されます。relay_logも指定されていない場合、デフォルトのレプリケーションチャネルのデフォルト名は、ホストマシンの名前を使用したhost_name-relay-bin.indexhost_name-relay-bin-channel.indexchannelはこのリレーログインデックスに記録されているレプリケーションチャネルの名前です。リレーログファイルのデフォルトの場所は、データディレクトリ、または
relay_logシステム変数を使用して指定されたその他の場所です。 ベース名に先頭の絶対パス名を追加して別のディレクトリを指定することで、relay_log_indexシステム変数を使用して別の場所を指定できます。レプリケーションサーバーのリレーログおよびリレーログインデックスには、バイナリログおよびバイナリログインデックスと同じ名前を付けることはできません。バイナリログおよびバイナリログインデックスの名前は、
--log-binおよび--log-bin-indexオプションで指定されます。 バイナリログとリレーログファイルのベース名が同じであれば、サーバーはエラーメッセージを発行し、起動しません。MySQL がサーバーオプションを解析する方法のため、サーバーの起動時にこの変数を指定する場合は、デフォルトのベース名は、オプションが実際に指定されていない場合にのみ使用されますという値を指定する必要があります。 サーバーの起動時に値を指定せずに
relay_log_indexシステム変数を指定すると、予期しない動作が発生する可能性があります。この動作は、使用される他のオプション、それらが指定されている順序、およびそれらがコマンド行とオプションファイルのどちらで指定されているかによって異なります。 MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.2「プログラムオプションの指定」を参照してください。 -
コマンド行形式 --relay-log-info-file=file_name非推奨 8.0.18 システム変数 relay_log_info_fileスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 デフォルト値 relay-log.infoこのシステム変数の使用は非推奨になりました。
relay_log_info_repository=FILEが設定されている場合、レプリカアプライアンスメタデータリポジトリのファイル名を設定するために使用されていました。relay_log_info_fileおよびrelay_log_info_repositoryシステム変数の使用は、アプライヤメタデータリポジトリのファイルの使用がクラッシュセーフテーブルに置き換えられたため、非推奨になりました。 適用者メタデータリポジトリの詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」 を参照してください。 -
コマンド行形式 --relay-log-info-repository=value非推奨 8.0.23 システム変数 relay_log_info_repositoryスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 文字列 デフォルト値 TABLE有効な値 FILETABLEこのシステム変数の使用は非推奨になりました。
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[={OFF|ON}]システム変数 relay_log_purgeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONリレーログファイルが不要になったときに自動的にパージするよう無効または有効にします。 デフォルト値は 1 (
ON) です。 -
コマンド行形式 --relay-log-recovery[={OFF|ON}]システム変数 relay_log_recoveryスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこの変数を有効にすると、サーバーの起動直後にリレーログリカバリが自動的に有効になります。 リカバリプロセスでは、新しいリレーログファイルを作成し、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の設定に違いはありません。注記この変数は、次のグループレプリケーションチャネルには影響しません:
group_replication_appliergroup_replication_recovery
外部ソースまたは別のグループからレプリケートしているチャネルなど、グループで実行されている他のチャネルは影響を受けます。
-
コマンド行形式 --relay-log-space-limit=#システム変数 relay_log_space_limitスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295すべてのリレーログに使用するスペースの最大量。
-
replication_optimize_for_static_plugin_configコマンド行形式 --replication-optimize-for-static-plugin-config[={OFF|ON}]導入 8.0.23 システム変数 replication_optimize_for_static_plugin_configスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFF準同期レプリケーションのパフォーマンスを向上させるには、共有ロックを使用し、不要なロック取得を回避します。 このシステム変数が有効になっている間は準同期レプリケーションプラグインをアンインストールできないため、アンインストールを完了する前にシステム変数を無効にする必要があります。
このシステム変数は、準同期レプリケーションプラグインのインストール前またはインストール後に有効にしたり、レプリケーションの実行中に有効にしたりできます。 準同期レプリケーションソースサーバーも、複製と同じロックメカニズムを使用するため、このシステム変数を有効にすることでパフォーマンス上の利点を得ることができます。
-
replication_sender_observe_commit_onlyコマンド行形式 --replication-sender-observe-commit-only[={OFF|ON}]導入 8.0.23 システム変数 replication_sender_observe_commit_onlyスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFF準同期レプリケーションのパフォーマンスを向上させるには、コールバックを制限します。 このシステム変数は、準同期レプリケーションプラグインのインストール前またはインストール後に有効にしたり、レプリケーションの実行中に有効にしたりできます。 準同期レプリケーションソースサーバーも、複製と同じロックメカニズムを使用するため、このシステム変数を有効にすることでパフォーマンス上の利点を得ることができます。
-
コマンド行形式 --report-host=host_nameシステム変数 report_hostスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 文字列 レプリカの登録時にソースにレポートされるレプリカのホスト名または IP アドレス。 この値は、ソースサーバーの
SHOW REPLICAS | SHOW SLAVE HOSTSの出力に表示されます。 レプリカ自体をソースに登録しない場合は、値を未設定のままにします。注記レプリカの接続後、ソースが TCP/IP ソケットからレプリカサーバーの IP アドレスを読み取るだけでは不十分です。 NAT およびその他のルーティングの問題のため、その IP はソースまたは他のホストからレプリカへの接続に有効でない可能性があります。
-
コマンド行形式 --report-password=nameシステム変数 report_passwordスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 文字列 レプリカの登録時にソースにレポートされるレプリカのアカウントパスワード。 この値は、ソースが
--show-slave-auth-infoで起動された場合に、ソースサーバー上のSHOW REPLICAS | SHOW SLAVE HOSTSの出力に表示されます。この変数の名前は、それ以外の意味を持つ場合もありますが、
report_passwordは MySQL ユーザー権限システムに接続されていないため、MySQL レプリケーションユーザーアカウントのパスワードと同じである必要はありません (または同じである可能性もあります)。 -
コマンド行形式 --report-port=port_numシステム変数 report_portスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Integer デフォルト値 [slave_port]最小値 0最大値 65535レプリカ登録時にソースにレポートされる、レプリカに接続するための TCP/IP ポート番号。 これは、レプリカがデフォルト以外のポートでリスニングしている場合、またはソースまたは他のクライアントからレプリカへの特別なトンネルがある場合にのみ設定します。 確実でない場合は、このオプションを使用しないでください。
このオプションのデフォルト値は、レプリカによって実際に使用されるポート番号です。 これは、
SHOW REPLICAS | SHOW SLAVE HOSTSによって表示されるデフォルト値でもあります。 -
コマンド行形式 --report-user=nameシステム変数 report_userスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 文字列 レプリカの登録時にソースにレポートされるレプリカのアカウントユーザー名。 この値は、ソースが
--show-slave-auth-infoで起動された場合に、ソースサーバー上のSHOW REPLICAS | SHOW SLAVE HOSTSの出力に表示されます。この変数の名前はそれ以外を意味する場合もありますが、
report_userは MySQL ユーザー権限システムに接続されていないため、必ずしも MySQL レプリケーションユーザーアカウントの名前と同じである必要はありません。 -
コマンド行形式 --rpl-read-size=#システム変数 rpl_read_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 8192最小値 8192最大値 4294967295rpl_read_sizeシステム変数は、バイナリログファイルおよびリレーログファイルから読み取られるデータの最小量をバイト単位で制御します。 これらのファイルに対する大量のディスク I/O アクティビティがデータベースのパフォーマンスを低下させている場合、ファイルデータがオペレーティングシステムによって現在キャッシュされていないと、読取りサイズを増やすとファイル読取りが減少し、I/O が停止する可能性があります。rpl_read_sizeの最小値およびデフォルト値は 8192 バイトです。 値は 4KB の倍数である必要があります。 バイナリログおよびリレーログファイルから読み取るスレッドごとに、この値のバッファーが割り当てられます。これには、ソース上のダンプスレッドやレプリカ上のコーディネータスレッドも含まれます。 したがって、大きな値を設定すると、サーバーのメモリー消費に影響する可能性があります。 -
コマンド行形式 --rpl-semi-sync-slave-enabled[={OFF|ON}]システム変数 rpl_semi_sync_slave_enabledスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFレプリカサーバーで準同期レプリケーションを有効にするかどうかを制御します。 プラグインを有効または無効にするには、この変数を
ONまたはOFF(あるいは 1 または 0) にそれぞれ設定します。 デフォルトはOFFです。この変数は、レプリカ側の準同期レプリケーションプラグインがインストールされている場合にのみ使用できます。
-
rpl_semi_sync_slave_trace_levelコマンド行形式 --rpl-semi-sync-slave-trace-level=#システム変数 rpl_semi_sync_slave_trace_levelスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 32レプリカサーバー上の準同期レプリケーションのデバッグトレースレベル。 許可できる値については、
rpl_semi_sync_master_trace_levelを参照してください。この変数は、レプリカ側の準同期レプリケーションプラグインがインストールされている場合にのみ使用できます。
-
コマンド行形式 --rpl-stop-slave-timeout=secondsシステム変数 rpl_stop_slave_timeoutスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 31536000最小値 2最大値 31536000この変数を設定することで、
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=#システム変数 slave_checkpoint_groupスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 512最小値 32最大値 524280ブロックサイズ 8SHOW REPLICA | SLAVE STATUSで示されているように、チェックポイント操作がコールされてステータスが更新されるまでにマルチスレッドレプリカで処理できるトランザクションの最大数を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべてのSTART REPLICA | SLAVEコマンドに適用されます。注記マルチスレッドレプリカは現在 NDB Cluster でサポートされていないため、この変数の設定は暗黙的に無視されます。 詳しくはセクション23.6.3「NDB Cluster レプリケーションの既知の問題」,をご覧ください。
この変数は、
slave_checkpoint_periodシステム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。この変数の最小許容値は 32 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、この場合の最小値は 1)。 効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。 (例外: このような丸めはデバッグサーバーでは実行されません。) サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。 -
コマンド行形式 --slave-checkpoint-period=#システム変数 slave_checkpoint_periodスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 300最小値 1最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295単位 milliseconds SHOW REPLICA | SLAVE STATUSで示されるように、マルチスレッドレプリカのステータスを更新するためにチェックポイント操作がコールされるまでに許容される最大時間 (ミリ秒) を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。注記マルチスレッドレプリカは現在 NDB Cluster でサポートされていないため、この変数の設定は暗黙的に無視されます。 詳しくはセクション23.6.3「NDB Cluster レプリケーションの既知の問題」,をご覧ください。
この変数は、
slave_checkpoint_groupシステム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。この変数の最小許容値は 1 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、この場合の最小値は 0)。 サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。 -
コマンド行形式 --slave-compressed-protocol[={OFF|ON}]非推奨 8.0.18 システム変数 slave_compressed_protocolスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFソースとレプリカの両方でサポートされている場合に、ソース/レプリカ接続プロトコルの圧縮を使用するかどうか。 この変数が無効 (デフォルト) の場合、接続は圧縮解除されます。 この変数への変更は、後続の接続試行時に有効になります。これには、
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=modeシステム変数 slave_exec_modeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 IDEMPOTENT(NDB)STRICT(その他)有効な値 IDEMPOTENTSTRICTレプリケーション中にレプリケーションスレッドが競合およびエラーを解決する方法を制御します。
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=dir_nameシステム変数 slave_load_tmpdirスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ディレクトリ名 デフォルト値 Value of --tmpdirレプリカが一時ファイルを作成するディレクトリの名前。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。 変数値は、デフォルトでは
tmpdirシステム変数の値、またはそのシステム変数が指定されていない場合に適用されるデフォルトと等しくなります。レプリケーション SQL スレッドは、
LOAD DATAステートメントをレプリケートするときに、リレーログから一時ファイルにロードされるファイルを抽出し、それらをテーブルにロードします。 ソースにロードされたファイルが膨大な場合、レプリカ上の一時ファイルも膨大になります。 したがって、このオプションを使用して、使用可能な領域が大量にある一部のファイルシステムにあるディレクトリに一時ファイルを配置するようレプリカに指示することをお薦めします。 その場合、リレーログも非常に大きいため、リレーログをそのファイルシステムに配置するようにrelay_logシステム変数を設定することもできます。このオプションで指定するディレクトリは、
LOAD DATAステートメントのレプリケートに使用される一時ファイルがマシンの再起動後も存続できるように、メモリーベースのファイルシステムではなくディスクベースのファイルシステムに配置する必要があります。 このディレクトリは、システム起動プロセス中にオペレーティングシステムによってクリアされるものではいけません。 ただし、一時ファイルが削除されている場合は、再起動後にレプリケーションを続行できるようになりました。 -
コマンド行形式 --slave-max-allowed-packet=#システム変数 slave_max_allowed_packetスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 1073741824最小値 1024最大値 1073741824このオプションは、レプリケーション 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=#システム変数 slave_net_timeoutスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 60最小値 1最大値 4294967295レプリカが接続の切断を考慮し、読取りを中断して再接続を試行するまでに、ソースからさらにデータまたはハートビートシグナルを待機する秒数。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべての
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=valueシステム変数 slave_parallel_typeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 DATABASE有効な値 DATABASELOGICAL_CLOCKマルチスレッドのレプリカ (
slave_parallel_workersが 0 より大きい値に設定されているレプリカ) の場合、slave_parallel_typeはレプリカでパラレルに実行できるトランザクションを決定するために使用されるポリシーを指定します。 この変数は、マルチスレッドが有効になっていないレプリカには影響しません。 指定可能な値は次のとおりです。LOGICAL_CLOCK: ソース上の同じバイナリロググループのコミットの一部であるトランザクションは、レプリカ上で並列に適用されます。 可能な場合は、トランザクション間の依存性がタイムスタンプに基づいて追跡され、追加のパラレル化が提供されます。 この値を設定すると、binlog_transaction_dependency_trackingシステム変数をソースで使用して、書込みセットがトランザクションで使用可能で、タイムスタンプと比較して改善された結果が得られる場合に、タイムスタンプのかわりに書込みセットがパラレル化に使用されるように指定できます。DATABASE: 異なるデータベースを更新するトランザクションはパラレルに適用されます。 この値は、データがソースで独立して同時に更新される複数のデータベースにパーティション化されている場合にのみ適しています。 このような制約はレプリカで違反する可能性があるため、クロスデータベース制約は存在できません。
slave_preserve_commit_order=1が設定されている場合、使用できるのはLOGICAL_CLOCKのみです。レプリケーショントポロジで複数レベルのレプリカが使用されている場合、
LOGICAL_CLOCKではレプリカがソースから離れている各レベルのパラレル化が実現されないことがあります。 可能な場合は、ソースでbinlog_transaction_dependency_trackingを使用してパラレル化にタイムスタンプのかわりに書込みセットを使用するように指定することで、この影響を軽減できます。binlog_transaction_compressionシステム変数を使用してバイナリログトランザクション圧縮が有効になっている場合、slave_parallel_typeがDATABASEに設定されていると、トランザクションがスケジュールされる前に、トランザクションの影響を受けるすべてのデータベースがマップされます。 バイナリログトランザクション圧縮をDATABASEポリシーとともに使用すると、イベントごとにマップおよびスケジュールされる圧縮されていないトランザクションと比較して並列度を減らすことができます。 -
コマンド行形式 --slave-parallel-workers=#システム変数 slave_parallel_workersスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 1024レプリカでマルチスレッドを有効にし、レプリケーショントランザクションをパラレルに実行するためのアプライヤスレッドの数を設定します。 値が 0 より大きい場合、レプリカは、指定された数のアプライヤスレッドと、それらを管理するためのコーディネータスレッドを持つマルチスレッドのレプリカです。 複数のレプリケーションチャネルを使用している場合、各チャネルにはこの数のスレッドがあります。
注記マルチスレッドレプリカは現在 NDB Cluster でサポートされていないため、この変数の設定は暗黙的に無視されます。 詳しくはセクション23.6.3「NDB Cluster レプリケーションの既知の問題」,をご覧ください。
レプリカでマルチスレッドが有効になっている場合、トランザクションの再試行がサポートされます。
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=#システム変数 slave_pending_jobs_size_maxスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 (≥ 8.0.12) 128Mデフォルト値 (8.0.11) 16M最小値 1024最大値 16EiB単位 bytes ブロックサイズ 1024マルチスレッドレプリカの場合、この変数は、まだ適用されていないイベントを保持するアプライヤキューで使用可能なメモリーの最大量 (バイト単位) を設定します。 この変数を設定しても、マルチスレッドが有効になっていないレプリカには影響しません。 この変数を設定しても、すぐには影響しません。 変数の状態は、後続のすべての
START REPLICA | SLAVEコマンドに適用されます。この変数に指定できる最小値は 1024 バイトです。デフォルトは 128MB です。 可能な最大値は 18446744073709551615 (16 exbibytes) です。 1024 バイトの正確な倍数でない値は、格納される前に 1024 バイトの次の小さい倍数に切り捨てられます。
この変数の値は弱い制限であり、通常のワークロードと一致するように設定できます。 異常に大きいイベントがこのサイズを超えると、すべてのワーカースレッドに空のキューが設定されてから処理されるまで、トランザクションは保持されます。 後続のすべてのトランザクションは、大規模なトランザクションが完了するまで保持されます。
-
コマンド行形式 --slave-preserve-commit-order[={OFF|ON}]システム変数 slave_preserve_commit_orderスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFマルチスレッドのレプリカ (
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_preserve_commit_order=1では、Exec_master_log_posがトランザクションが実行された位置より遅れているソースバイナリログの位置ラグは防止されません。 セクション17.5.1.34「レプリケーションとトランザクションの非一貫性」を参照してください。レプリカが
--binlog-do-dbなどのバイナリログでフィルタを使用する場合、slave_preserve_commit_order=1はコミット順序およびトランザクション履歴を保持しません。slave_preserve_commit_order=1では、非トランザクション DML 更新の順序は保持されません。 これらはリレーログ内で、それらより前のトランザクションの前にコミットされる可能性があるため、レプリカリレーログから実行された一連のトランザクションにギャップが生じる可能性があります。MySQL 8.0.19 より前のリリースでは、関連するオブジェクトが存在しない場合、
slave_preserve_commit_order=1はIF EXISTS句を含むステートメントの順序を保持しません。 これらはリレーログ内で、それらより前のトランザクションの前にコミットされる可能性があるため、レプリカリレーログから実行された一連のトランザクションにギャップが生じる可能性があります。ステートメントベースのレプリケーションが使用中で、トランザクションおよび非トランザクションの両方のストレージエンジンがソースでロールバックされる非 XA トランザクションに参加している場合、レプリカ上のコミット順序を保持する制限が発生することがあります。 通常、ソースでロールバックされる非 XA トランザクションはレプリカにレプリケートされませんが、この特定の状況ではトランザクションがレプリカにレプリケートされる可能性があります。 これが発生した場合、バイナリロギングのないマルチスレッドレプリカはトランザクションのロールバックを処理しないため、レプリカ上のコミット順序は、その場合のトランザクションのリレーログ順序とは異なります。
-
コマンド行形式 --slave-rows-search-algorithms=value非推奨 8.0.18 システム変数 slave_rows_search_algorithmsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Set デフォルト値 INDEX_SCAN,HASH_SCAN有効な値 TABLE_SCAN,INDEX_SCANINDEX_SCAN,HASH_SCANTABLE_SCAN,HASH_SCANTABLE_SCAN,INDEX_SCAN,HASH_SCAN(INDEX_SCAN,HASH_SCAN と同等)行ベースのロギングおよびレプリケーションのために行のバッチを準備する場合、このシステム変数は、行で一致を検索する方法、特にハッシュスキャンを使用するかどうかを制御します。 このシステム変数の使用は非推奨になりました。 デフォルト設定の
INDEX_SCAN,HASH_SCANはパフォーマンスに最適で、すべてのシナリオで正しく機能します。 セクション17.5.1.27「レプリケーションおよび行検索」を参照してください。 -
コマンド行形式 --slave-skip-errors=nameシステム変数 slave_skip_errorsスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 文字列 デフォルト値 OFF有効な値 OFF[list of error codes]allddl_exist_errors通常、レプリケーションはレプリカでエラーが発生すると停止するため、データの非一貫性を手動で解決できます。 この変数を指定すると、ステートメントが変数値にリストされているエラーのいずれかを返したときに、レプリケーション SQL スレッドはレプリケーションを続行します。
-
コマンド行形式 --slave-sql-verify-checksum[={OFF|ON}]システム変数 slave_sql_verify_checksumスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONレプリケーション SQL スレッドがリレーログから読み取られたチェックサムを使用してデータを検証するようにします。 不一致が発生した場合、レプリカはエラーで停止します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。
注記レプリケーション I/O スレッドは、ネットワーク経由でイベントを受け入れるときに、可能であれば常にチェックサムを読み取ります。
-
コマンド行形式 --slave-transaction-retries=#システム変数 slave_transaction_retriesスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 10最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295シングルスレッドまたはマルチスレッドレプリカ上のレプリケーション 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=setシステム変数 slave_type_conversionsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Set デフォルト値 有効な値 ALL_LOSSYALL_NON_LOSSYALL_SIGNEDALL_UNSIGNED行ベースレプリケーションの使用時にレプリカで有効な型変換モードを制御します。 その値は、リスト内のゼロ個以上の要素のカンマ区切りセットです:
ALL_LOSSY,ALL_NON_LOSSY,ALL_SIGNED,ALL_UNSIGNED。 ソースとレプリカ間の型変換を禁止するには、この変数を空の文字列に設定します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。行ベースレプリケーションで属性の昇格と降格に適用できるタイプ変換モードの詳細については、行ベースレプリケーション: 属性の昇格と降格を参照してください。
-
システム変数 sql_slave_skip_counterスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295レプリカがスキップするソースからのイベントの数。 このオプションを設定しても、すぐには影響しません。 変数は次の
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「トランザクションのスキップ」を参照してください。重要この変数を設定して指定されたイベント数をスキップすると、レプリカがイベントグループの途中で開始される場合、レプリカは次のイベントグループの開始を検出し、その時点から開始するまでスキップし続けます。 詳細は、セクション17.1.7.3「トランザクションのスキップ」を参照してください。
-
コマンド行形式 --sync-master-info=#システム変数 sync_master_infoスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 10000最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295レプリカが接続メタデータリポジトリを更新するまでのイベント数。 接続メタデータリポジトリが MySQL 8.0 のデフォルトである
InnoDBテーブルとして格納されている場合、この数のイベントの後に更新されます。 接続メタデータリポジトリが、MySQL 8.0 から非推奨になったファイルとして格納されている場合、レプリカは、この数のイベントの後に、(fdatasync()を使用して)master.infoファイルをディスクに同期します。 デフォルト値は 10000 で、ゼロ値はリポジトリが更新されないことを意味します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。 -
コマンド行形式 --sync-relay-log=#システム変数 sync_relay_logスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 10000最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295この変数の値が 0 より大きい場合は、すべての
sync_relay_logイベントがリレーログに書き込まれたあとに、MySQL サーバーはそのリレーログをディスクに同期します (fdatasync()を使用)。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。sync_relay_logを 0 に設定すると、ディスクへの同期は実行されません。この場合、サーバーはオペレーティングシステムに依存してほかのファイルに関してリレーログの内容をときどきフラッシュします。値 1 は、予期しない停止が発生した場合にリレーログから最大 1 つのイベントが失われるため、もっとも安全な選択です。 しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。 予期しない停止に対して最も回復可能なレプリカの設定の組合せの詳細は、セクション17.4.2「レプリカの予期しない停止の処理」 を参照してください。
-
コマンド行形式 --sync-relay-log-info=#システム変数 sync_relay_log_infoスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 10000最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295レプリカが適用者メタデータリポジトリを更新するまでのトランザクションの数。 アプライヤメタデータリポジトリが MySQL 8.0 のデフォルトである
InnoDBテーブルとして格納されている場合、トランザクションのたびに更新され、このシステム変数は無視されます。 アプライヤメタデータリポジトリが、MySQL 8.0 で非推奨になったファイルとして格納されている場合、レプリカは、この数のトランザクションの後に、(fdatasync()を使用して)relay-log.infoファイルをディスクに同期します。sync_relay_log_infoのデフォルト値は 10000 で、ゼロ値はファイルの内容がオペレーティングシステムによってのみフラッシュされることを意味します。 この変数の設定は、実行中のチャネルを含め、すべてのレプリケーションチャネルに対してただちに有効になります。