レプリケーションチャネルが GTID を持たないレプリケートされたトランザクションに GTID を割り当て、GTID ベースのレプリケーションを使用しないソースから使用するレプリカへのレプリケーションを有効にします。 マルチソースレプリカの場合、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用するチャネルと使用しないチャネルを混在させることができます。 デフォルトは OFF で、この機能は使用されません。

LOCAL は、レプリカ独自の UUID (server_uuid 設定) を含む GTID を割り当てます。uuid は、レプリケーションソースサーバーの server_uuid 設定など、指定された UUID を含む GTID を割り当てます。 非ローカル UUID を使用すると、レプリカで発生したトランザクションと、ソースで発生したトランザクション、およびマルチソースレプリカの場合は異なるソースで発生したトランザクションを区別できます。 選択した UUID は、レプリカ自体での使用にのみ意味があります。 ソースによって送信されたトランザクションのいずれかに GTID がすでにある場合、その GTID は保持されます。

Group Replication に固有のチャネルでは ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用できませんが、Group Replication グループメンバーであるサーバーインスタンス上の別のソースの非同期レプリケーションチャネルでは使用できます。 その場合、GTID を作成するための UUID として Group Replication グループ名を指定しないでください。

ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を LOCAL または uuid に設定するには、レプリカに gtid_mode=ON が設定されている必要があり、後で変更することはできません。 このオプションは、バイナリログファイルの位置ベースのレプリケーションを持つソースで使用されるため、チャネルに MASTER_AUTO_POSITION=1 を設定することはできません。 このオプションを設定する前に、レプリケーション SQL スレッドとレプリケーション I/O スレッドの両方を停止する必要があります。

その他の制限および詳細は、セクション17.1.3.6「GTID のないソースから GTID のあるレプリカへのレプリケーション」 を参照してください。

ソースから公開キーをリクエストすることで、RSA キーペアベースのパスワード交換を有効にします。 このオプションは、caching_sha2_password 認証プラグインで認証されるレプリカに適用されます。 このプラグインを使用して認証されるアカウントによる接続の場合、ソースはリクエストされないかぎり公開キーを送信しないため、クライアントでリクエストまたは指定する必要があります。 MASTER_PUBLIC_KEY_PATH が指定され、有効な公開キーファイルが指定されている場合は、GET_MASTER_PUBLIC_KEY よりも優先されます。 caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) で認証されるレプリケーションユーザーアカウントを使用していて、セキュアな接続を使用していない場合は、このオプションまたは MASTER_PUBLIC_KEY_PATH オプションを指定して、RSA 公開キーをレプリカに提供する必要があります。

レプリカが指定されたサーバーから発生したイベントを無視するようにします。 このオプションは、0 個以上のサーバー ID のコンマ区切りリストを取ります。 サーバーからのログローテーションおよび削除イベントは無視されず、リレーログに記録されます。

循環レプリケーションでは、発信元のサーバーは通常、独自のイベントのターミネータとして機能するため、これらのイベントが複数回適用されることはありません。 そのため、このオプションは、循環内のいずれかのサーバーが削除されたときの循環レプリケーションで役立ちます。 1、2、3、および 4 のサーバー ID を持つ 4 台のサーバーを含む循環レプリケーションセットアップが存在するとき、サーバー 3 に障害が発生したとします。 サーバー 2 からサーバー 4 へのレプリケーションを開始してギャップを埋める場合、サーバー 4 で発行する CHANGE MASTER TO ステートメントに IGNORE_SERVER_IDS = (3) を含めて、サーバー 3 の代わりにサーバー 2 をソースとして使用するように指示できます。 それにより、サーバー 4 は、使用されなくなっているサーバーで発信されたすべてのステートメントを無視し、伝播しなくなります。

IGNORE_SERVER_IDS にサーバーの独自の ID が含まれているときに、--replicate-same-server-id オプションが有効な状態でそのサーバーが起動された場合は、エラーが発生します。

ソースメタデータリポジトリおよび SHOW REPLICA | SLAVE STATUS の出力では、現在無視されているサーバーのリストが提供されます。 詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」およびセクション13.7.7.35「SHOW REPLICA | SLAVE STATUS ステートメント」を参照してください。

IGNORE_SERVER_IDS オプションを指定せずに CHANGE MASTER TO ステートメントを発行した場合、既存のリストは保持されます。 無視されるサーバーのリストをクリアするには、このオプションを空のリストとともに使用する必要があります。

CHANGE MASTER TO IGNORE_SERVER_IDS = ();

RESET REPLICA | SLAVE ALL により、IGNORE_SERVER_IDS がクリアされます。

GTID ベースのレプリケーションを使用してレプリカがソースに接続しようとします。 このオプションは、レプリケーション SQL スレッドとレプリケーション I/O スレッドの両方が停止している場合にのみ、CHANGE MASTER TO で使用できます。

レプリカとソースの両方で GTID が有効になっている必要があります (レプリカでは GTID_MODE=ON、ON_PERMISSIVE,または OFF_PERMISSIVE、ソースでは GTID_MODE=ON)。 接続には自動配置が使用されるため、MASTER_LOG_FILE および MASTER_LOG_POS で表される座標は使用されず、これらのオプションのいずれかまたは両方を MASTER_AUTO_POSITION = 1 とともに使用するとエラーが発生します。 レプリカでマルチソースレプリケーションが有効になっている場合は、適用可能なレプリケーションチャネルごとに MASTER_AUTO_POSITION = 1 オプションを設定する必要があります。

MASTER_AUTO_POSITION = 1 が設定されている場合、レプリカは初期接続ハンドシェイクで、すでに受信、コミット、またはその両方を行ったトランザクションを含む GTID セットを送信します。 ソースは、GTID がレプリカによって送信される GTID セットに含まれていないバイナリログに記録されたすべてのトランザクションを送信することによって応答します。 この交換により、レプリカがまだ記録またはコミットしていない GTID を持つトランザクションのみがソースから送信されるようになります。 ダイヤモンドトポロジの場合と同様に、レプリカが複数のソースからトランザクションを受信する場合、自動スキップ機能によってトランザクションが 2 回適用されないようにします。 レプリカによって送信される GTID セットの計算方法の詳細は、セクション17.1.3.3「GTID 自動配置」 を参照してください。

ソースによって送信されるべきトランザクションのいずれかがソースバイナリログからパージされているか、別の方法で gtid_purged システム変数の GTID セットに追加されている場合、ソースはエラー ER_MASTER_HAS_PURGED_REQUIRED_GTIDS をレプリカに送信し、レプリケーションは開始しません。 欠落しているパージ済トランザクションの GTID が識別され、警告メッセージ ER_FOUND_MISSING_GTIDS のソースエラーログにリストされます。 また、トランザクションの交換中に、レプリカが GTID 内のソース UUID を持つトランザクションを記録またはコミットしたが、ソース自体がそれらをコミットしていないことが判明した場合、ソースはレプリカにエラー ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER を送信し、レプリケーションは開始しません。 これらの状況の処理方法の詳細は、セクション17.1.3.3「GTID 自動配置」 を参照してください。

レプリケーションが GTID 自動配置を有効にして実行されているかどうかを確認するには、パフォーマンススキーマの replication_connection_status テーブルまたは SHOW REPLICA | SLAVE STATUS の出力を確認します。 MASTER_AUTO_POSITION オプションを再度無効にすると、レプリカはファイルベースレプリケーションに戻ります。その場合は、MASTER_LOG_FILE または MASTER_LOG_POS オプションのいずれかまたは両方も指定する必要があります。

複数のネットワークインタフェースを持つレプリカで使用するために、ソースへの接続に選択するレプリカネットワークインタフェースを決定します。 このオプションで構成されたアドレスは、SHOW REPLICA | SLAVE STATUS からの出力の Master_Bind カラムに表示されます (存在する場合)。 ソースメタデータリポジトリテーブル mysql.slave_master_info では、値は Master_bind カラムとして表示されます。 レプリカを特定のネットワークインタフェースにバインドする機能は、NDB Cluster でもサポートされています。

レプリケーションソースサーバーへの接続に許可される圧縮アルゴリズムを指定します。 使用可能なアルゴリズムは、protocol_compression_algorithms システム変数の場合と同じです。 デフォルト値は uncompressed です。 MASTER_COMPRESSION_ALGORITHMS は、MySQL 8.0.18 の時点で使用可能です。

MASTER_COMPRESSION_ALGORITHMS の値は、slave_compressed_protocol システム変数が無効な場合にのみ適用されます。 slave_compressed_protocol が有効な場合は、MASTER_COMPRESSION_ALGORITHMS よりも優先され、ソースとレプリカの両方がそのアルゴリズムをサポートしている場合は、ソースへの接続で zlib 圧縮が使用されます。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

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

ソースへの接続がタイムアウトした後にレプリカが試行する再接続の間隔を指定します。 試行は、MASTER_RETRY_COUNT オプションによって制限されます。 両方のデフォルト設定が使用されている場合、レプリカは再接続試行 (MASTER_CONNECT_RETRY=60) の間 60 秒待機し、60 日間 (MASTER_RETRY_COUNT=86400) 再接続を試行し続けます。 これらの値はソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。

レプリカが遅延する必要があるソースからの遅延秒数を指定します。 ソースから受信したイベントは、ソースでの実行より少なくとも interval 秒後に実行されません。 デフォルトは 0 です。 interval が 0 から 2³¹-1 までの範囲の負ではない整数でない場合は、エラーが発生します。 詳細は、セクション17.4.11「遅延レプリケーション」を参照してください。 MASTER_DELAY オプションを使用する CHANGE MASTER TO ステートメントは、レプリケーション SQL スレッドの停止時に実行中のレプリカで実行できます。

ハートビート間隔を制御します。これにより、接続がまだ良好な場合に、データが存在しないときに接続タイムアウトが発生しなくなります。 ハートビートシグナルは、その秒数が経過するとレプリカに送信され、ソースバイナリログがイベントで更新されるたびに待機期間がリセットされます。 したがって、ハートビートは、これより長い期間バイナリログファイルに未送信のイベントがない場合にのみ、ソースによって送信されます。

ハートビート間隔 interval は、0 から 4294967 秒の範囲の小数値およびミリ秒単位の解像度です。ゼロ以外の最小値は 0.001 です。 interval を 0 に設定すると、ハートビートが完全に無効になります。 ハートビート間隔のデフォルトは、slave_net_timeout システム変数の値の半分です。 ソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。 RESET REPLICA | SLAVE を発行すると、ハートビート間隔がデフォルト値にリセットされます。

slave_net_timeout システム変数は、レプリカがソースからのデータまたはハートビートシグナルのいずれかを待機する秒数を指定します。この秒数を過ぎると、レプリカは接続が切断されたとみなし、読取りを中断して再接続を試行します。 デフォルト値は 60 秒 (1 分) です。 slave_net_timeout の値またはデフォルト設定を変更しても、明示的に設定されているか、以前に計算されたデフォルトを使用しているかにかかわらず、ハートビート間隔は自動的には変更されないことに注意してください。 @@GLOBAL.slave_net_timeout を現在のハートビート間隔より小さい値に設定すると、警告が発行されます。 slave_net_timeout が変更された場合は、接続タイムアウトの前にハートビートシグナルが発生するように、CHANGE MASTER TO を発行してハートビート間隔を適切な値に調整する必要もあります。 これを行わない場合、ハートビートシグナルは効果がなく、ソースからデータを受信しない場合、レプリカは再接続を繰り返し試行してゾンビダンプスレッドを作成できます。

レプリケーションソースサーバーのホスト名または IP アドレス。 レプリカはこれを使用してソースに接続します。

MASTER_HOST または MASTER_PORT を指定した場合、レプリカは、ソースサーバーが以前とは異なることを前提とします (オプション値が現在の値と同じであっても)。) この場合、ソースバイナリログファイルの名前と位置の古い値は適用できなくなるため、ステートメントに MASTER_LOG_FILE と MASTER_LOG_POS を指定しないと、MASTER_LOG_FILE=''と MASTER_LOG_POS=4 は暗黙的に追加されます。

MASTER_HOST='' を設定する (つまり、その値を明示的に空の文字列に設定する) ことは、MASTER_HOST をまったく設定しないことと同じではありません。 MASTER_HOST を空の文字列に設定しようとすると、エラーで失敗します。

バイナリログファイル名、およびレプリケーション I/O スレッドが次回のスレッド起動時にソースバイナリログからの読み取りを開始するそのファイル内の場所。 バイナリログファイルの位置ベースのレプリケーションを使用している場合は、これらのオプションを指定します。 MASTER_LOG_FILE には、ソースサーバーで使用可能な特定のバイナリログファイル (MASTER_LOG_FILE='binlog.000145'など) の数値接尾辞が含まれている必要があります。 MASTER_LOG_POS は、レプリカがそのファイルの読取りを開始する数値位置です。 MASTER_LOG_POS=4 は、バイナリログファイルでイベントの開始を表します。

MASTER_LOG_FILE または MASTER_LOG_POS のどちらかを指定する場合は、RELAY_LOG_FILE や RELAY_LOG_POS を指定できません。 MASTER_LOG_FILE または MASTER_LOG_POS のいずれかを指定する場合は、GTID ベースのレプリケーション用の MASTER_AUTO_POSITION = 1 も指定できません。

MASTER_LOG_FILE も MASTER_LOG_POS も指定されていない場合、レプリカは CHANGE MASTER TO が発行される前のレプリケーション SQL スレッドの最後の座標を使用します。 これにより、レプリケーション SQL スレッドがレプリケーション I/O スレッドと比較して遅延していても、レプリケーションの不連続性がなくなります。

レプリケーションソースサーバーへの接続に使用するレプリケーションユーザーアカウントのパスワード。 MASTER_PASSWORD を指定する場合は、MASTER_USER も必要です。

CHANGE MASTER TO ステートメントでレプリケーションユーザーアカウントに使用されるパスワードの長さは、32 文字に制限されています。 32 文字を超えるパスワードを使用しようとすると、CHANGE MASTER TO で障害が発生します。

レプリカがレプリケーションソースサーバーへの接続に使用する TCP/IP ポート番号。

MASTER_HOST または MASTER_PORT を指定した場合、レプリカは、ソースサーバーが以前とは異なることを前提とします (オプション値が現在の値と同じであっても)。) この場合、ソースバイナリログファイルの名前と位置の古い値は適用できなくなるため、ステートメントに MASTER_LOG_FILE と MASTER_LOG_POS を指定しないと、MASTER_LOG_FILE=''と MASTER_LOG_POS=4 は暗黙的に追加されます。

ソースが必要とする公開キーのレプリカ側のコピーを含むファイルへのパス名を指定することで、RSA キーペアベースのパスワード交換を有効にします。 ファイルは PEM 形式である必要があります。 このオプションは、sha256_password または caching_sha2_password 認証プラグインで認証されるレプリカに適用されます。 (sha256_password の場合、MASTER_PUBLIC_KEY_PATH は、MySQL が OpenSSL を使用して構築された場合にのみ使用できます。) caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) で認証されるレプリケーションユーザーアカウントを使用していて、セキュアな接続を使用していない場合は、このオプションまたは GET_MASTER_PUBLIC_KEY=1 オプションを指定して、RSA 公開キーをレプリカに提供する必要があります。

slave_net_timeout システム変数によって決定される、ソースへの接続がタイムアウトした後にレプリカが行う再接続の最大試行回数を設定します。 レプリカを再接続する必要がある場合、タイムアウトの直後に最初の再試行が行われます。 試行の間隔は、MASTER_CONNECT_RETRY オプションで指定します。 両方のデフォルト設定が使用されている場合、レプリカは再接続試行 (MASTER_CONNECT_RETRY=60) の間 60 秒待機し、60 日間 (MASTER_RETRY_COUNT=86400) 再接続を試行し続けます。 これらの値はソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。 MASTER_RETRY_COUNT は、--master-retry-count サーバーの起動オプションより優先されます。

レプリカが暗号化および暗号化を使用してレプリケーション接続を保護する方法を指定します。 これらのオプションは、SSL サポートなしでコンパイルされたレプリカでも変更できます。 これらはソースメタデータリポジトリに保存されますが、レプリカで SSL サポートが有効になっていない場合は無視されます。 MASTER_SSL_xxx および MASTER_TLS_xxx オプションは、暗号化接続のコマンドオプション で説明されている --ssl-xxx および --tls-xxx クライアントオプションと同じ機能を実行します。 2 つのオプションセット間の対応、および MASTER_SSL_xxx オプションと MASTER_TLS_xxx オプションを使用したセキュアな接続の設定については、セクション17.3.1「暗号化接続を使用するためのレプリケーションの設定」 を参照してください。

レプリケーションソースサーバーへの接続に使用するレプリケーションユーザーアカウントのユーザー名。

MASTER_USER=''を指定して空のユーザー名を設定することはできますが、レプリケーションチャネルは空のユーザー名で開始できません。 MySQL 8.0.21 より前のリリースでは、セキュリティ上の目的で以前に使用した資格証明をレプリケーションメタデータリポジトリからクリアする必要がある場合にのみ、空の MASTER_USER ユーザー名を設定します。 これらのリリースでは、リポジトリから空のユーザー名が読み取られた場合 (グループレプリケーションチャネルの自動再起動時など)、デフォルトのユーザー名を置換できるバグのため、後でチャネルを使用しないでください。 MySQL 8.0.21 からは、レプリケーションチャネルを開始する START REPLICA | SLAVE ステートメントまたは START GROUP_REPLICATION ステートメントを使用して常にユーザー資格証明を指定する場合、空の MASTER_USER ユーザー名を設定し、後でチャネルを使用できます。 このアプローチでは、レプリケーションチャネルを再起動するためにオペレータの介入が常に必要ですが、ユーザー資格証明はレプリケーションメタデータリポジトリに記録されません。

実行中の CHANGE MASTER TO ステートメントのテキスト (MASTER_USER と MASTER_PASSWORD の値を含む) は、並列 SHOW PROCESSLIST ステートメントの出力で確認できます。 (START REPLICA | SLAVE ステートメントの完全なテキストは、SHOW PROCESSLIST にも表示されます。)

zstd 圧縮アルゴリズムを使用するレプリケーションソースサーバーへの接続に使用する圧縮レベル。 許可されるレベルは 1 から 22 で、大きい値は圧縮レベルの増加を示します。 デフォルトの zstd 圧縮レベルは 3 です。 圧縮レベルの設定は、zstd 圧縮を使用しない接続には影響しません。 MASTER_ZSTD_COMPRESSION_LEVEL は、MySQL 8.0.18 の時点で使用可能です。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

レプリケーションソースサーバーへの TCP/IP 接続に使用するネットワークネームスペース。 このオプションを省略すると、レプリカからの接続にはデフォルト (グローバル) 名前空間が使用されます。 ネットワークネームスペースのサポートを実装していないプラットフォームでは、レプリカがソースに接続しようとすると障害が発生します。 ネットワークネームスペースの詳細は、セクション5.1.14「ネットワークネームスペースのサポート」 を参照してください。 NETWORK_NAMESPACE は、MySQL 8.0.22 の時点で使用可能です。

指定されたチャネルのセキュリティコンテキストを提供するユーザーアカウントを指定します。 NULL(デフォルト) は、セキュリティコンテキストが使用されないことを意味します。 PRIVILEGE_CHECKS_USER は、MySQL 8.0.18 の時点で使用可能です。

ユーザーアカウントのユーザー名とホスト名は、セクション6.2.4「アカウント名の指定」 で説明されている構文に従う必要があり、ユーザーは匿名ユーザー (ユーザー名が空白) または CURRENT_USER であってはなりません。 アカウントには、REPLICATION_APPLIER 権限と、チャネルでレプリケートされたトランザクションを実行するために必要な権限が必要です。 アカウントに必要な権限の詳細は、セクション17.3.3「レプリケーション権限チェック」 を参照してください。 レプリケーションチャネルを再起動すると、その時点から権限チェックが適用されます。 チャネルを指定せず、他のチャネルが存在しない場合は、ステートメントがデフォルトチャネルに適用されます。

PRIVILEGE_CHECKS_USER が設定されており、これを強制するように REQUIRE_ROW_FORMAT を設定できる場合は、行ベースのバイナリロギングを使用することを強くお勧めします。 たとえば、実行中のレプリカでチャネル channel_1 に対する権限チェックを開始するには、次のステートメントを発行します:

mysql> STOP REPLICA | SLAVE FOR CHANNEL 'channel_1';
mysql> CHANGE MASTER TO
         PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
         REQUIRE_ROW_FORMAT = 1,
         FOR CHANNEL 'channel_1';
mysql> START REPLICA | SLAVE FOR CHANNEL 'channel_1';

次回のスレッド起動時にレプリケーション SQL スレッドがレプリカリレーログからの読取りを開始するリレーログファイル名およびそのファイル内の場所。 MASTER_LOG_FILE または MASTER_LOG_POS を使用している場合、これらのオプションは使用できません。

RELAY_LOG_FILE では、絶対パスまたは相対パスのいずれかを使用でき、MASTER_LOG_FILE と同じベース名を使用します。 RELAY_LOG_FILE、RELAY_LOG_POS またはその両方のオプションを使用する CHANGE MASTER TO ステートメントは、レプリケーション SQL スレッドの停止時に実行中のレプリカで実行できます。 少なくともいずれかのレプリケーション SQL スレッドとレプリケーション I/O スレッドが実行されている場合、リレーログは保持されます。 両方のスレッドが停止すると、RELAY_LOG_FILE または RELAY_LOG_POS のいずれかが指定されていないかぎり、すべてのリレーログファイルが削除されます。 Group Replication applier チャネル (group_replication_applier) には I/O スレッドがなく、SQL スレッドのみがあることに注意してください。 このチャネルでは、SQL スレッドの停止時にリレーログは保持されません。

レプリケーションチャネルによる行ベースのレプリケーションイベントの処理のみを許可します。 このオプションにより、レプリケーションアプライアンスは一時テーブルの作成や LOAD DATA INFILE リクエストの実行などのアクションを実行できなくなり、チャネルのセキュリティが向上します。 グループレプリケーションチャネルは REQUIRE_ROW_FORMAT セットで自動的に作成され、これらのチャネルのオプションは変更できません。 詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。 REQUIRE_ROW_FORMAT は、MySQL 8.0.19 の時点で使用可能です。

レプリカが主キーチェック用に独自のポリシーを選択できるようにします。 レプリケーションチャネルのオプションが ON に設定されている場合、レプリカはレプリケーション操作で常に sql_require_primary_key システム変数に値 ON を使用し、主キーが必要です。 このオプションが OFF に設定されている場合、レプリカはレプリケーション操作で sql_require_primary_key システム変数に常に値 OFF を使用するため、ソースで必要な場合でも主キーは必要ありません。 REQUIRE_TABLE_PRIMARY_KEY_CHECK オプションが STREAM(デフォルト) に設定されている場合、レプリカは各トランザクションのソースからレプリケートされた値を使用します。 REQUIRE_TABLE_PRIMARY_KEY_CHECK は、MySQL 8.0.20 の時点で使用可能です。

マルチソースレプリケーションの場合、REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF に設定すると、レプリカは異なるソースのレプリケーションチャネル間で動作を正規化し、sql_require_primary_key システム変数の一貫性のある設定を維持できます。 ON を使用すると、複数のソースが同じテーブルセットを更新する場合に、主キーの偶発的な損失から保護されます。 OFF を使用すると、主キーを操作できるソースを、操作できないソースと連携させることができます。

PRIVILEGE_CHECKS_USER が設定されている場合、REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF に設定することは、制限付きセッション変数を設定するためのセッション管理レベルの権限がユーザーアカウントに必要ないことを意味します。これは、sql_require_primary_key の値を各トランザクションのソース設定と一致するように変更するために必要です。 詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。

1 つ以上の代替レプリケーションサーバーが使用可能な場合 (レプリケートされたデータを共有する複数の MySQL サーバーまたはサーバーグループが存在する場合)、レプリケーションチャネルの非同期接続フェイルオーバーメカニズムをアクティブ化します。 SOURCE_CONNECTION_AUTO_FAILOVER は、MySQL 8.0.22 の時点で使用可能です。 非同期接続フェイルオーバーメカニズムは、MASTER_CONNECT_RETRY および MASTER_RETRY_COUNT によって制御されている再接続試行を使い果たした後に引き継ぎます。 asynchronous_connection_failover_add_source および asynchronous_connection_failover_delete_source UDF を使用して管理する、指定されたソースリストから選択された代替ソースにレプリカを再接続します。 サーバーの管理対象グループを追加および削除するには、かわりに asynchronous_connection_failover_add_managed および asynchronous_connection_failover_delete_managed UDF を使用します。 詳細は、セクション17.4.9「非同期接続フェイルオーバーによるソースの切替え」を参照してください。