group_replication_advertise_recovery_endpoints

group_replication_autorejoin_tries

group_replication_consistency

group_replication_exit_state_action

group_replication_flow_control_applier_threshold

group_replication_flow_control_certifier_threshold

group_replication_flow_control_hold_percent

group_replication_flow_control_max_commit_quota

group_replication_flow_control_member_quota_percent

group_replication_flow_control_min_quota

group_replication_flow_control_min_recovery_quota

group_replication_flow_control_mode

group_replication_flow_control_period

group_replication_flow_control_release_percent

group_replication_force_members

group_replication_member_expel_timeout

group_replication_member_weight

group_replication_transaction_size_limit

group_replication_unreachable_majority_timeout

group_replication_auto_increment_increment

group_replication_communication_max_message_size

group_replication_compression_threshold

group_replication_message_cache_size

group_replication_transaction_size_limit

group_replication_single_primary_mode

group_replication_enforce_update_everywhere_checks

group_replication_gtid_assignment_block_size

default_table_encryption

lower_case_table_names

transaction_write_set_extraction

group_replication_advertise_recovery_endpoints

このシステム変数の値は、Group Replication の実行中に変更できます。 変更はすぐにメンバーに反映されます。 ただし、システム変数の以前の値をすでに受け取っている結合メンバーは、その値を引き続き使用します。 値の変更後に結合されたメンバーのみが新しい値を受け取ります。

group_replication_advertise_recovery_endpoints は、結合メンバーが分散リカバリのために状態転送のために既存のメンバーへの接続を確立する方法を指定します。 この接続は、リモートクローニング操作とドナーのバイナリログからの状態転送の両方に使用されます。

デフォルト設定の DEFAULT の値は、参加メンバーが MySQL Server hostname および port システム変数で指定されている既存のメンバー標準 SQL クライアント接続を使用することを意味します。 report_port システム変数で代替ポート番号が指定されている場合は、かわりにそのポート番号が使用されます。 「パフォーマンススキーマ」テーブル replication_group_members では、この接続アドレスとポート番号が MEMBER_HOST および MEMBER_PORT フィールドに表示されます。 これは、MySQL 8.0.20 までのリリースでのグループメンバーの動作です。

DEFAULT のかわりに、既存のメンバーが使用する参加メンバーに通知する分散リカバリエンドポイントを指定できます。 分散リカバリエンドポイントを提供することで、管理者は、グループメンバーへの通常の MySQL クライアント接続とは別に分散リカバリトラフィックを制御できます。 メンバーの結合では、リストで指定された順序で各エンドポイントが順に試行されます。

分散リカバリエンドポイントを IP アドレスとポート番号のカンマ区切りリストとして指定します。次に例を示します:

group_replication_advertise_recovery_endpoints= "127.0.0.1:3306,127.0.0.1:4567,[::1]:3306,localhost:3306"

IPv4 アドレスと IPv6 アドレスおよびホスト名は、任意の組合せで使用できます。 IPv6 アドレスは大カッコで囲んで指定する必要があります。 ホスト名はローカル IP アドレスに解決される必要があります。 ワイルドカードアドレス書式は使用できず、空のリストは指定できません。 標準 SQL クライアント接続は、分散リカバリエンドポイントのリストに自動的には含まれないことに注意してください。 エンドポイントとして使用する場合は、リストに明示的に含める必要があります。

分散リカバリエンドポイントとして IP アドレスとポートを選択する方法、およびメンバーを結合する方法の詳細は、セクション18.4.3.1.1「分散リカバリエンドポイントのアドレスの選択」 を参照してください。 要件のサマリーは次のとおりです:

group_replication_allow_local_lower_version_join

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_allow_local_lower_version_join では、現在のサーバーがグループより低いバージョンの MySQL Server を実行している場合でも、グループに参加できます。 デフォルト設定の OFF では、既存のグループメンバーより低いバージョンを実行しているサーバーはレプリケーショングループに参加できません。 この標準ポリシーは、グループのすべてのメンバーがメッセージを交換し、トランザクションを適用できることを確認します。 MySQL 8.0.17 以上を実行しているメンバーは、互換性をチェックするときにリリースのパッチバージョンを考慮することに注意してください。 MySQL 8.0.16 以下または MySQL 5.7 を実行しているメンバーには、メジャーバージョンのみが考慮されます。

次のシナリオでのみ、group_replication_allow_local_lower_version_join を ON に設定します:

group_replication_auto_increment_increment

このシステム変数は、すべてのグループメンバーで同じ値を持つ必要があります。 グループレプリケーションの実行中は、このシステム変数の値を変更できません。 各グループメンバーでグループレプリケーションを停止し、システム変数の値を変更してから、グループレプリケーションを再起動する必要があります。 このプロセス中、システム変数の値はグループメンバー間で異なってもかまいませんが、グループメンバーの一部のトランザクションはロールバックされる可能性があります。

group_replication_auto_increment_increment は、このサーバーインスタンスで実行されるトランザクションの自動増分カラムの連続する値の間隔を決定します。 間隔を追加すると、グループメンバーに対する書込みに対して重複する自動増分値が選択されないため、トランザクションがロールバックされます。 デフォルト値の 7 は、使用可能な値の数とレプリケーショングループの最大許容サイズ (9 メンバー) のバランスを表します。 グループのメンバー数が多いか少ない場合は、グループレプリケーションが開始される前に、グループメンバーの予想数と一致するようにこのシステム変数を設定できます。

グループレプリケーションがサーバーインスタンスで開始されると、サーバーシステム変数 auto_increment_increment の値がこの値に変更され、サーバーシステム変数 auto_increment_offset の値がサーバー ID に変更されます。 グループレプリケーションが停止すると、変更は元に戻されます。 これらの変更は、auto_increment_increment および auto_increment_offset のそれぞれのデフォルト値が 1 の場合にのみ行われ、元に戻されます。 これらの値がすでにデフォルトから変更されている場合、Group Replication はそれらを変更しません。 MySQL 8.0 からは、グループレプリケーションが単一プライマリモードで、サーバー書込みが 1 つのみの場合も、システム変数は変更されません。

group_replication_autorejoin_tries

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 動作が必要であることを意味する問題が発生すると、システム変数 current 値が読み取られます。

group_replication_autorejoin_tries では、メンバーが明示された場合、または group_replication_unreachable_majority_timeout 設定に到達する前にグループの大部分にアクセスできない場合に、メンバーが自動的にグループに再参加しようとする試行回数を指定します。 メンバー削除または到達不能な大部分のタイムアウトに達すると、(現在のプラグインオプション値を使用して) 再結合を試みてから、指定された試行回数までさらに自動再結合を試みます。 自動再結合の試行に失敗すると、メンバーは次の試行の 5 分前に待機します。 指定された試行回数がメンバーの再参加または停止なしで使い果たされた場合、メンバーは group_replication_exit_state_action システム変数で指定されたアクションに進みます。

MySQL 8.0.20 までは、デフォルト設定は 0 です。つまり、メンバーは自動的に再結合を試みません。 MySQL 8.0.21 からは、デフォルト設定は 3 です。これは、メンバーがグループへの再参加を自動的に 3 回試行し、それぞれの間に 5 分間試行することを意味します。 最大 2016 回の試行を指定できます。

自動再結合の試行中および試行の間、メンバーはスーパー読取り専用モードのままで書込みを受け入れませんが、時間の経過とともに失効した読取りの可能性を高くして、メンバーに対して読取りを実行できます。 一定期間失効した読取りの可能性を許容できない場合は、group_replication_autorejoin_tries を 0 に設定します。 自動再結合機能、およびこのオプションの値を選択する際の考慮事項の詳細は、セクション18.6.6.3「Auto-Rejoin」 を参照してください。

group_replication_bootstrap_group

group_replication_bootstrap_group は、グループをブートストラップするようにこのサーバーを構成します。 このシステム変数は、グループを初めて起動するとき、またはグループ全体を再起動するときに、あるサーバーおよびのみで設定する必要があります。 グループがブートストラップされたら、このオプションを OFF に設定します。 動的にも構成ファイルでも、OFF に設定する必要があります。 グループの実行中に 2 つのサーバーを起動するか、このオプションを設定して 1 つのサーバーを再起動すると、人工的なスプリットブレーン状況が発生し、同じ名前の独立した 2 つのグループがブートストラップされる場合があります。

group_replication_clone_threshold

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_clone_threshold では、分散リカバリプロセス中に参加メンバーへの状態転送のためにリモートクローニング操作の使用をトリガーする既存のメンバー (ドナー) と参加メンバー (受信者) の間のトランザクションギャップを多数のトランザクションとして指定します。 参加メンバーと適切なドナーの間のトランザクションギャップがしきい値を超えると、グループレプリケーションはリモートクローニング操作で分散リカバリを開始します。 トランザクションギャップがしきい値を下回る場合、またはリモートクローニング操作が技術的に可能でない場合、Group Replication はドナーのバイナリログからの状態転送に直接進みます。

この関数を使用するには、クローニングをサポートするようにドナーと参加メンバーの両方を事前に設定する必要があります。 その手順は、セクション18.4.3.2「分散リカバリのためのクローニング」を参照してください。 リモートクローニング操作が実行されると、group_replication_start_on_boot=ON が設定されている場合は、グループレプリケーションによって管理され、必要なサーバーの再起動も含まれます。 そうでない場合は、サーバーを手動で再起動する必要があります。 リモートクローニング操作では、結合メンバーの既存のデータディクショナリが置換されますが、結合メンバーに他のグループメンバーに存在しない追加のトランザクションがある場合、これらのトランザクションはクローニング操作によって消去されるため、グループレプリケーションによってチェックされ、続行されません。

デフォルト設定 (GTID 内のトランザクションに許可される最大シーケンス番号) は、ドナーのバイナリログからの状態転送が、クローニングではなく実質的に常に試行されることを意味します。 ただし、結合メンバーに必要なトランザクションが既存のグループメンバーのバイナリログで使用できないためなど、ドナーバイナリログからの状態転送が不可能な場合、グループレプリケーションはしきい値に関係なく常にクローニング操作を実行しようとします。 レプリケーショングループでクローニングをまったく使用しない場合は、クローンプラグインをメンバーにインストールしないでください。

group_replication_communication_debug_options

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_communication_debug_options は、グループ通信システム (GCS) やグループ通信エンジン (XCom、Paxos バリアント) などの様々なグループレプリケーションコンポーネントに提供するデバッグメッセージのレベルを構成します。 デバッグ情報は、データディレクトリの GCS_DEBUG_TRACE ファイルに格納されます。

文字列として指定された使用可能なオプションのセットを組み合せることができます。 次のオプションを使用できます。

デバッグレベルを GCS_DEBUG_NONE に設定すると、他のオプションを指定せずに指定した場合にのみ有効になります。 デバッグレベルを GCS_DEBUG_ALL に設定すると、他のすべてのオプションがオーバーライドされます。

group_replication_communication_max_message_size

このシステム変数は、すべてのグループメンバーで同じ値を持つ必要があります。 グループレプリケーションの実行中は、このシステム変数の値を変更できません。 各グループメンバーでグループレプリケーションを停止し、システム変数の値を変更してから、グループレプリケーションを再起動する必要があります。 このプロセス中、システム変数の値はグループメンバー間で異なってもかまいませんが、グループメンバーの一部のトランザクションはロールバックされる可能性があります。

group_replication_communication_max_message_size では、グループレプリケーション通信の最大メッセージサイズを指定します。 このサイズより大きいメッセージは、個別に送信され、受信者によって再アセンブルされるフラグメントに自動的に分割されます。 詳細は、セクション18.6.4「メッセージの断片化」を参照してください。

10485760 バイト (10 MiB) の最大メッセージサイズがデフォルトで設定されています。つまり、MySQL 8.0.16 からのリリースでは、断片化がデフォルトで使用されます。 最大許容値は、slave_max_allowed_packet システム変数の最大値 1073741824 バイト (1 GB) と同じです。 アプライヤスレッドは slave_max_allowed_packet より大きいメッセージフラグメントを処理できないため、group_replication_communication_max_message_size の設定は slave_max_allowed_packet の設定より小さくする必要があります。 断片化をオフにするには、group_replication_communication_max_message_size にゼロ値を指定します。

レプリケーショングループのメンバーが断片化を使用するには、グループ通信プロトコルのバージョンが MySQL 8.0.16 以上である必要があります。 group_replication_get_communication_protocol() UDF を使用して、グループ通信プロトコルのバージョンを表示します。 下位バージョンが使用されている場合、グループメンバーはメッセージを断片化しません。 すべてのグループメンバーがサポートしている場合は、group_replication_set_communication_protocol() UDF を使用して、グループ通信プロトコルを上位バージョンに設定できます。 詳細は、セクション18.4.1.4「グループ通信プロトコルバージョンの設定」を参照してください。

group_replication_components_stop_timeout

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_components_stop_timeout では、グループレプリケーションが停止時に各コンポーネントを待機するタイムアウトを秒単位で指定します。

group_replication_compression_threshold

このシステム変数は、すべてのグループメンバーで同じ値を持つ必要があります。 このシステム変数の値は、Group Replication の実行中に変更できます。 変更は、メンバーでグループレプリケーションを停止して再起動した後、各グループメンバーで有効になります。 このプロセス中、システム変数の値はグループメンバー間で異なってもかまいませんが、メッセージ配信の効率はすべてのメンバーで同じではありません。

group_replication_compression_threshold では、グループメンバー間で送信されるメッセージに圧縮が適用されるしきい値をバイト単位で指定します。 このシステム変数をゼロに設定すると、圧縮は無効になります。

グループレプリケーションでは、LZ4 圧縮アルゴリズムを使用して、グループで送信されるメッセージを圧縮します。 LZ4 圧縮アルゴリズムでサポートされる最大入力サイズは 2113929216 バイトです。 この制限は、XCom で受け入れられる最大メッセージサイズと一致する、group_replication_compression_threshold システム変数の最大可能値を下回っています。 LZ4 圧縮アルゴリズムでは、メッセージ圧縮が有効な場合、このサイズを超えるトランザクションはコミットできないため、group_replication_compression_threshold に 2113929216 バイトを超える値を設定しないでください。

詳細は、セクション18.6.3「メッセージ圧縮」を参照してください。

group_replication_consistency

このシステム変数の値は、Group Replication の実行中に変更できます。group_replication_consistency は Group Replication プラグイン固有の変数ではなくサーバーシステム変数であるため、変更を有効にするために Group Replication を再起動する必要はありません。 システム変数のセッション値の変更はただちに有効になり、グローバル値の変更は変更後に開始される新しいセッションに対して有効になります。 このシステム変数のグローバル設定を変更するには、GROUP_REPLICATION_ADMIN 権限が必要です。

group_replication_consistency は、グループが提供するトランザクションの一貫性保証を制御します。 一貫性はグローバルに構成することも、トランザクションごとに構成することもできます。group_replication_consistency は、単一のプライマリグループで新しく選択されたプライマリによって使用されるフェンシングメカニズムも構成します。 変数の効果は、読取り専用 (RO) トランザクションと読取り/書込み (RW) トランザクションの両方で考慮する必要があります。 次のリストは、トランザクションの一貫性保証を高めるために、この変数に指定できる値を示しています:

詳細は、セクション18.4.2「トランザクション一貫性保証」を参照してください。

group_replication_enforce_update_everywhere_checks

このシステム変数は、グループ全体の構成設定です。 値の変更を有効にするには、すべてのグループメンバーで同じ値を持つ必要があり、グループレプリケーションの実行中は変更できず、グループ (group_replication_bootstrap_group=ON を使用したサーバーによるブートストラップ) を完全に再起動する必要があります。 MySQL 8.0.16 から、group_replication_switch_to_single_primary_mode() および group_replication_switch_to_multi_primary_mode() UDF を使用して、グループの実行中にこのシステム変数の値を変更できます。 詳細は、セクション18.4.1.2「グループモードの変更」を参照してください。

group_replication_enforce_update_everywhere_checks は、マルチプライマリ更新の厳密な整合性チェックをどこでも有効または無効にします。 デフォルトでは、チェックは無効になっています。 シングルプライマリモードでは、すべてのグループメンバーでこのオプションを無効にする必要があります。 マルチプライマリモードでは、このオプションを有効にすると、ステートメントは次のようにチェックされ、マルチプライマリモードと互換性があることが確認されます:

group_replication_exit_state_action

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 動作が必要であることを意味する問題が発生すると、システム変数 current 値が読み取られます。

group_replication_exit_state_action では、たとえばアプライヤエラーが発生した後、大部分が失われた場合、または疑わしいタイムアウトのためにグループの別のメンバーがグループを明示する場合などに、このサーバーインスタンスが意図せずグループを離れたときのグループレプリケーションの動作を構成します。 大部分が失われた場合にメンバーがグループを離れるタイムアウト期間は group_replication_unreachable_majority_timeout システム変数によって設定され、疑わしい場合のタイムアウト期間は group_replication_member_expel_timeout システム変数によって設定されます。 削除されたグループメンバーは、グループに再接続するまで削除されたことを認識しないため、指定されたアクションが実行されるのは、メンバーが再接続を管理している場合、またはメンバーがそれ自体で疑わしいことを引き起こして削除した場合のみです。

疑わしいタイムアウトまたは大部分の損失が原因でグループメンバーが削除された場合、メンバーの group_replication_autorejoin_tries システム変数が自動再結合の試行回数を指定するように設定されていると、最初にスーパー読取り専用モードで指定された回数試行し、次に group_replication_exit_state_action で指定されたアクションに従います。 アプライヤエラーの場合、自動再結合はリカバリできないため試行されません。

group_replication_exit_state_action が READ_ONLY に設定されている場合、メンバーが誤ってグループを終了するか、自動再結合の試行を使い果たすと、インスタンスは MySQL をスーパー読取り専用モードに切り替えます (システム変数 super_read_only を ON に設定します)。 READ_ONLY 終了アクションは、システム変数が導入される前の MySQL 8.0 リリースの動作であり、MySQL 8.0.16 から再度デフォルトになりました。

group_replication_exit_state_action が OFFLINE_MODE に設定されている場合、メンバーが誤ってグループを終了するか、自動再結合の試行を使い果たすと、インスタンスは MySQL をオフラインモードに切り替えます (システム変数 offline_mode を ON に設定します)。 このモードでは、接続クライアントユーザーは次のリクエストで切断され、CONNECTION_ADMIN 権限 (または非推奨の SUPER 権限) を持つクライアントユーザーを除き、接続は受け入れられなくなります。 Group Replication は、システム変数 super_read_only を ON に設定することもできるため、クライアントが CONNECTION_ADMIN または SUPER 権限で接続されていても更新を行うことはできません。 OFFLINE_MODE 終了アクションは、MySQL 8.0.18 から使用できます。

group_replication_exit_state_action が ABORT_SERVER に設定されている場合、メンバーが意図せずグループを終了するか、自動再結合の試行を使い果たすと、インスタンスは MySQL を停止します。 この設定は、システム変数が MySQL 8.0.15 に追加されたときの MySQL 8.0.12 のデフォルトでした。

このオプションの使用方法および exit アクションが実行される状況の完全なリストの詳細は、セクション18.6.6.4「終了処理」 を参照してください。

group_replication_flow_control_applier_threshold

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_applier_threshold では、フロー制御をトリガーするアプライヤキュー内の待機中トランザクションの数を指定します。

group_replication_flow_control_certifier_threshold

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_certifier_threshold では、フロー制御をトリガーする証明者キュー内の待機中トランザクションの数を指定します。

group_replication_flow_control_hold_percent

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_hold_percent では、フロー制御下のクラスタがバックログで捕捉できるように、未使用のままになるグループ割当ての割合を定義します。 値 0 は、作業バックログを捕捉するために割当て制限の一部が予約されていないことを意味します。

group_replication_flow_control_max_commit_quota

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_max_commit_quota では、フロー制御が有効になっている間、グループの最大フロー制御割当て制限または任意の期間の最大使用可能割当て制限が定義されます。 値 0 は、最大割当て制限が設定されていないことを意味します。 このシステム変数の値は、group_replication_flow_control_min_quota および group_replication_flow_control_min_recovery_quota より小さくできません。

group_replication_flow_control_member_quota_percent

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_member_quota_percent では、割当て制限の計算時にメンバーが使用可能とみなす必要がある割当て制限の割合が定義されます。 値 0 は、割当て制限を最後の期間のライターであったメンバー間で均等に分割する必要があることを意味します。

group_replication_flow_control_min_quota

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_min_quota は、最後の期間に実行された計算済の最小目標とは関係なく、メンバーに割り当てることができる最小フロー制御目標を制御します。 値 0 は、最小割当て制限がないことを意味します。 このシステム変数の値は group_replication_flow_control_max_commit_quota より大きくできません。

group_replication_flow_control_min_recovery_quota

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_min_recovery_quota は、最後の期間に実行された計算済の最小割当て制限とは関係なく、グループ内の別のリカバリメンバーのためにメンバーに割り当てることができる最小割当て制限を制御します。 値 0 は、最小割当て制限がないことを意味します。 このシステム変数の値は group_replication_flow_control_max_commit_quota より大きくできません。

group_replication_flow_control_mode

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_mode では、フロー制御に使用されるモードを指定します。

group_replication_flow_control_period

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_period では、フロー制御メッセージが送信されてフロー制御管理タスクが実行されるまで待機する秒数を定義します。

group_replication_flow_control_release_percent

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。

group_replication_flow_control_release_percent では、フロー制御でライターメンバーを制限する必要がなくなった場合に、グループ割当て制限を解放する方法を定義します。この割合は、フロー制御期間ごとの割当て制限の増加です。 値 0 は、フロー制御しきい値が制限内になると、割当て制限が単一のフロー制御反復で解放されることを意味します。 範囲を使用すると、割当て制限を現在の割当て制限の最大 10 倍までリリースできます。これにより、主にフロー制御期間が大きく、割当て制限が非常に小さい場合に、より高度な適応が可能になります。

group_replication_force_members

このシステム変数は、新しいグループメンバーシップを強制するために使用されます。 このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 システム変数の値を設定する必要があるのは、グループに残すグループメンバーのいずれかのみです。 新しいグループメンバーシップを強制的に実行する必要がある状況と、このシステム変数を使用する際に従う手順の詳細は、セクション18.4.4「ネットワークパーティション化」 を参照してください。

group_replication_force_members では、ピアアドレスのリストをカンマ区切りリスト (host1:port1、host2:port2 など) として指定します。 リストに含まれていない既存のメンバーは、グループの新しいビューを受信せず、ブロックされます。 メンバーとして続行する既存のメンバーごとに、各メンバーの group_replication_local_address システム変数で指定されているように、IP アドレスまたはホスト名とポートを含める必要があります。 IPv6 アドレスは大カッコで囲んで指定する必要があります。 例:

"198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061,example.org:33061"

Group Replication (XCom) のグループ通信エンジンは、指定された IP アドレスが有効な形式であることをチェックし、現在アクセスできないグループメンバーが含まれていないことをチェックします。 それ以外の場合、新しい構成は検証されないため、グループのアクセス可能なメンバーであるオンラインサーバーのみを含めるように注意する必要があります。 リスト内の不正な値または無効なホスト名があると、グループが無効な構成でブロックされる可能性があります。

新しいメンバーシップ構成を強制的に実行する前に、除外するサーバーが停止していることを確認することが重要です。 そうでない場合は、停止してから続行します。 まだオンラインのグループメンバーは新しい構成を自動的に形成でき、これがすでに行われている場合は、さらに新しい構成を強制すると、グループに人工的なスプリットブレイン状況が作成される可能性があります。

group_replication_force_members システム変数を使用して新しいグループメンバーシップを強制し、グループのブロックを解除した後、必ずシステム変数をクリアしてください。START GROUP_REPLICATION ステートメントを発行するには、group_replication_force_members が空である必要があります。

group_replication_group_name

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_group_name は、このサーバーインスタンスが属するグループの名前を指定します。これは有効な UUID である必要があります。 この UUID は、バイナリログ内のグループレプリケーショントランザクションの GTID を設定するときに内部的に使用されます。

group_replication_group_seeds

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_group_seeds は、参加メンバーが現在のすべてのグループメンバーの詳細を取得するために接続できるグループメンバーのリストです。 参加メンバーは、これらの詳細を使用してグループメンバーを選択して接続し、グループとの同期に必要なデータを取得します。 このリストは、シードメンバーの group_replication_local_address システム変数 (MySQL Server hostname および port システム変数で指定されたシードメンバーの SQL クライアント接続ではなく) で構成されている、含まれる各シードメンバーの単一の内部ネットワークアドレスまたはホスト名で構成されます。 シードメンバーのアドレスは、host1:port1、host2:port2 などのカンマ区切りリストとして指定されます。 IPv6 アドレスは大カッコで囲んで指定する必要があります。 例:

group_replication_group_seeds= "198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061, example.org:33061"

この変数に指定する値は、START GROUP_REPLICATION ステートメントが発行され、Group Communication System (GCS) が使用可能になるまで検証されないことに注意してください。

通常、このリストはグループのすべてのメンバーで構成されますが、シードするグループメンバーのサブセットを選択できます。 リストには、少なくとも 1 つの有効なメンバーアドレスが含まれている必要があります。 各アドレスは、Group Replication の開始時に検証されます。 リストに有効なメンバーアドレスが含まれていない場合、START GROUP_REPLICATION の発行は失敗します。

サーバーは、レプリケーショングループに参加するときに、その group_replication_group_seeds システム変数にリストされている最初のシードメンバーに接続しようとします。 接続が拒否された場合、参加メンバーはリスト内の他の各シードメンバーに順番に接続しようとします。 結合メンバーがシードメンバーに接続しても、結果としてレプリケーショングループに追加されない場合 (たとえば、シードメンバーの allowlist に結合メンバーアドレスがなく、接続を閉じているため)、結合メンバーはリスト内の残りのシードメンバーを順番に試行し続けます。

参加メンバーは、シードメンバーが group_replication_group_seeds オプションで通知するプロトコル (IPv4 または IPv6) と同じプロトコルを使用してシードメンバーと通信する必要があります。 グループレプリケーションの IP アドレス権限のために、シードメンバーの許可リストには、シードメンバーが提供するプロトコルの参加メンバーの IP アドレス、またはそのプロトコルのアドレスに解決されるホスト名が含まれている必要があります。 このアドレスのプロトコルがシードメンバーに通知されたプロトコルと一致しない場合は、参加メンバー group_replication_local_address に加えて、このアドレスまたはホスト名を設定して許可する必要があります。 参加メンバーに適切なプロトコルの許可されたアドレスがない場合、その接続試行は拒否されます。 詳細は、セクション18.5.1「グループレプリケーション IP アドレスの権限」を参照してください。

group_replication_gtid_assignment_block_size

このシステム変数は、グループ全体の構成設定です。 値の変更を有効にするには、すべてのグループメンバーで同じ値を持つ必要があり、グループレプリケーションの実行中は変更できず、グループ (group_replication_bootstrap_group=ON を使用したサーバーによるブートストラップ) を完全に再起動する必要があります。

group_replication_gtid_assignment_block_size では、各グループメンバー用に予約されている連続 GTID の数を指定します。 各メンバーは独自のブロックを消費し、必要に応じてより多くのブロックを予約します。

group_replication_ip_allowlist

group_replication_ip_allowlist は、group_replication_ip_whitelist のかわりに MySQL 8.0.22 から使用できます。 グループレプリケーションの実行中は、このシステム変数の値を変更できません。

group_replication_ip_allowlist は、グループへの接続を許可するホストを指定します。 group_replication_local_address の各グループメンバーに指定するアドレスは、レプリケーショングループ内の他のサーバーで許可されている必要があります。 この変数に指定する値は、START GROUP_REPLICATION ステートメントが発行され、Group Communication System (GCS) が使用可能になるまで検証されないことに注意してください。

デフォルトでは、このシステム変数は、ホスト上でアクティブなプライベートサブネットワークからの接続を許可する AUTOMATIC に設定されています。 Group Replication (XCom) のグループ通信エンジンは、ホスト上のアクティブなインタフェースを自動的にスキャンし、プライベートサブネットワーク上のアドレスを持つインタフェースを識別します。 IPv4 および (MySQL 8.0.14 から) IPv6 のこれらのアドレスと localhost IP アドレスを使用して、Group Replication 許可リストを作成します。 アドレスが自動的に許可される範囲のリストについては、セクション18.5.1「グループレプリケーション IP アドレスの権限」 を参照してください。

プライベートアドレスの自動許可リストは、プライベートネットワーク外のサーバーからの接続には使用できません。 異なるマシン上にあるサーバーインスタンス間のグループレプリケーション接続の場合、パブリック IP アドレスを指定し、明示的な許可リストとして指定する必要があります。 許可リストにエントリを指定した場合、プライベートアドレスは自動的に追加されないため、これらのいずれかを使用する場合は、明示的に指定する必要があります。 localhost IP アドレスは自動的に追加されます。

group_replication_ip_allowlist オプションの値として、次の任意の組合せを指定できます:

MySQL 8.0.14 より前では、ホスト名は IPv4 アドレスにのみ解決できました。 MySQL 8.0.14 から、ホスト名は IPv4 アドレス、IPv6 アドレス、またはその両方に解決できます。 ホスト名が IPv4 アドレスと IPv6 アドレスの両方に解決される場合、IPv4 アドレスは常にグループレプリケーション接続に使用されます。 CIDR 表記をホスト名または IP アドレスと組み合せて使用すると、特定のネットワーク接頭辞を持つ IP アドレスのブロックを許可できますが、指定したサブネット内のすべての IP アドレスが制御下にあることを確認してください。

allowlist の各エントリはカンマで区切る必要があります。 例:

"192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24"

結合メンバーに IPv4 group_replication_local_address がある場合、またはその逆の場合に、グループのシードメンバーのいずれかが IPv6 アドレスとともに group_replication_group_seeds オプションにリストされている場合は、シードメンバーによって提供されるプロトコル (またはそのプロトコルのアドレスに解決されるホスト名) の結合メンバーの代替アドレスも設定して許可する必要があります。 詳細は、セクション18.5.1「グループレプリケーション IP アドレスの権限」を参照してください。

たとえば、異なるサブネットを分離しておくために、セキュリティ要件に応じて異なるグループメンバーに異なる許可リストを構成できます。 ただし、これにより、グループの再構成時に問題が発生する可能性があります。 それ以外の場合に特定のセキュリティ要件がない場合は、グループのすべてのメンバーで同じ許可リストを使用します。 詳細は、セクション18.5.1「グループレプリケーション IP アドレスの権限」を参照してください。

ホスト名の場合、名前解決は、別のサーバーによって接続リクエストが行われた場合にのみ行われます。 解決できないホスト名は許可リストの検証で考慮されず、警告メッセージがエラーログに書き込まれます。 前方確認の逆引き DNS (FCrDNS) 検証は、解決されたホスト名に対して実行されます。

group_replication_ip_whitelist

MySQL 8.0.22 からは、group_replication_ip_whitelist は非推奨であり、group_replication_ip_allowlist を使用して置き換えられます。 どちらのシステム変数の場合も、デフォルト値は AUTOMATIC です。 いずれかのシステム変数がユーザー定義値に設定されていて、もう一方が設定されていない場合は、変更された値が使用されます。 両方のシステム変数がユーザー定義の値に設定されている場合は、group_replication_ip_allowlist の値が使用されます。

新しいシステム変数は古いシステム変数と同じように機能しますが、用語のみが変更されています。 group_replication_ip_allowlist の動作の説明は、古いシステム変数と新しいシステム変数の両方に適用されます。

group_replication_local_address

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_local_address は、メンバーが他のメンバーからの接続用に提供するネットワークアドレスを、host:port フォーマット文字列として指定して設定します。 このアドレスは、リモート XCom インスタンス間の TCP 通信用のグループレプリケーション (XCom、Paxos バリアント) のためにグループ通信エンジンによって使用されるため、グループのすべてのメンバーがアクセスできる必要があります。 ローカルインスタンスとの通信は、共有メモリーを使用して入力チャネルを介して行われます。

group_replication_local_address で指定するアドレスまたはホスト名は、グループレプリケーションによって、レプリケーショングループ内のグループメンバーの一意の識別子として使用されます。 ホスト名または IP アドレスがすべて異なるかぎり、レプリケーショングループのすべてのメンバーに同じポートを使用でき、ポートがすべて異なるかぎり、すべてのメンバーに同じホスト名または IP アドレスを使用できます。 group_replication_local_address の推奨ポートは 33061 です。 この変数に指定した値は、START GROUP_REPLICATION ステートメントが発行され、Group Communication System (GCS) が使用可能になるまで検証されないことに注意してください。

group_replication_local_address によって構成されたネットワークアドレスは、すべてのグループメンバーが解決できる必要があります。 たとえば、各サーバーインスタンスが固定ネットワークアドレスを持つ異なるマシン上にある場合、10.0.0.1 などのマシンの IP アドレスを使用できます。 ホスト名を使用する場合は、完全修飾名を使用し、DNS、正しく構成された/etc/hosts ファイルまたはその他の名前解決プロセスを介して解決できることを確認する必要があります。 MySQL 8.0.14 からは、IPv6 アドレス (またはそれらに解決されるホスト名) と IPv4 アドレスを使用できます。 IPv6 アドレスは、ポート番号を区別するために大カッコで囲む必要があります。次に例を示します:

group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

サーバーインスタンスのグループレプリケーションのローカルアドレスとして指定されたホスト名が IPv4 アドレスと IPv6 アドレスの両方に解決される場合、IPv4 アドレスは常にグループレプリケーション接続に使用されます。 IPv6 ネットワークおよび IPv4 を使用するメンバーと IPv6 を使用するメンバーが混在するレプリケーショングループに対するグループレプリケーションサポートの詳細は、セクション18.4.5「IPv6 および IPv6 と IPv4 の混合グループのサポート」 を参照してください。

グループレプリケーションの IP アドレス権限のために、group_replication_local_address の各グループメンバーに指定するアドレスを、レプリケーショングループ内の他のサーバー上の group_replication_ip_allowlist (MySQL 8.0.22 から) または group_replication_ip_whitelist システム変数のリストに追加する必要があります。 グループのシードメンバーのいずれかが IPv6 アドレスとともに group_replication_group_seeds オプションにリストされている場合このメンバーが IPV4 group_replication_local_address であれば (またはその逆の場合)、必要なプロトコル (またはそのプロトコルのアドレスに解決されるホスト名) に対してこのメンバーの代替アドレスを設定して許可する必要もあります。 詳細は、セクション18.5.1「グループレプリケーション IP アドレスの権限」を参照してください。

group_replication_member_expel_timeout

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 Group Replication がタイムアウトをチェックするたびに、システム変数の現在の値が読み取られます。 グループのすべてのメンバーが同じ設定を持つことは必須ではありませんが、予期しない実行を回避するためにお薦めします。

group_replication_member_expel_timeout では、疑わしいグループを作成した後、メンバーが失敗した疑いがあるグループから追い出されるまでにグループレプリケーショングループメンバーが待機する期間を秒単位で指定します。 疑いが作成される前の最初の 5 秒間の検出期間は、この時間の一部としてカウントされません。 MySQL 8.0.20 まで、group_replication_member_expel_timeout の値はデフォルトで 0 に設定されます。これは、待機期間がなく、疑わしいメンバーが 5 秒間の検出期間の終了直後に実行できることを意味します。 MySQL 8.0.21 からは、値はデフォルトで 5 に設定されます。つまり、疑わしいメンバーは、5 秒間の検出期間の 5 秒後に強制的に実行されます。

グループメンバーの group_replication_member_expel_timeout の値の変更は、そのグループメンバーの既存および将来の疑いに対してただちに有効になります。 したがって、これを方法として使用すると、疑わしいメンバーを強制的にタイムアウトして削除し、グループ構成を変更できます。 詳細は、セクション18.6.6.1「Expel タイムアウト」を参照してください。

group_replication_member_expel_timeout の値を大きくすると、低速または安定していないネットワークで不要な削除が発生しないようにしたり、一時的なネットワークの停止やマシンの速度低下が予想される場合に役立ちます。 疑わしいメンバーがタイムアウトする前に再度アクティブになると、残りのグループメンバーによってバッファされたすべてのメッセージが適用され、オペレータの介入なしで ONLINE 状態になります。 最大 3600 秒 (1 時間) までのタイムアウト値を指定できます。 XCom メッセージキャッシュが、指定した期間内の予想されるメッセージ量と最初の 5 秒間の検出期間を含むのに十分な大きさであることを確認することが重要です。そうでない場合、メンバーは再接続できません。 group_replication_message_cache_size システム変数を使用して、キャッシュサイズ制限を調整できます。 詳細は、セクション18.6.5「XCom キャッシュ管理」を参照してください。

タイムアウトを超えた場合、疑わしいメンバーは疑わしいタイムアウトの直後に削除する責任があります。 メンバーが通信を再開でき、削除されたビューを受信し、メンバーに自動再結合の試行回数を指定する group_replication_autorejoin_tries システム変数が設定されている場合、スーパー読取り専用モードでは、指定された回数グループへの再参加を試行します。 メンバーに自動再結合の試行が指定されていない場合、または指定された試行回数を使い果たした場合は、システム変数 group_replication_exit_state_action で指定されたアクションに従います。

group_replication_member_expel_timeout 設定の使用の詳細は、セクション18.6.6.1「Expel タイムアウト」 を参照してください。 このシステム変数が使用できない場合に不要な削除を回避するための代替軽減戦略については、セクション18.9.2「グループレプリケーションの制限事項」 を参照してください。

group_replication_member_weight

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 システム変数の現在の値は、フェイルオーバー状況が発生したときに読み取られます。

group_replication_member_weight では、既存のプライマリが単一プライマリグループから離れる場合など、フェイルオーバー時にプライマリとして選択されるメンバーの可能性に影響を与えるためにメンバーに割り当てることができる重みの割合を指定します。 プライマリのスケジュールされたメンテナンス中やフェイルオーバー時に特定のハードウェアが優先されるように、メンバーに数値の重みを割り当てて特定のメンバーが選択されるようにします。

メンバーが次のように構成されているグループの場合:

新しいプライマリの選択時に、前述のメンバーは member-2, member-3, member-4 および member-1 としてソートされます。 これにより、フェイルオーバー時に新しいプライマリとして member-2 が選択されます。 詳細は、セクション18.1.3.1「シングルプライマリモード」を参照してください。

group_replication_message_cache_size

このシステム変数は、すべてのグループメンバーで同じ値を持つ必要があります。 このシステム変数の値は、Group Replication の実行中に変更できます。 変更は、メンバーでグループレプリケーションを停止して再起動した後、各グループメンバーで有効になります。 このプロセス中、システム変数の値はグループメンバー間で異なってもかまいませんが、切断された場合にメンバーが再接続できないことがあります。

group_replication_message_cache_size は、グループレプリケーション (XCom) のグループ通信エンジンでメッセージキャッシュに使用可能なメモリーの最大量を設定します。 XCom メッセージキャッシュには、コンセンサスプロトコルの一部としてグループメンバー間で交換されるメッセージ (およびそのメタデータ) が保持されます。 メッセージキャッシュは、他のグループメンバーと通信できなかった期間後にグループに再接続するメンバーによる、欠落したメッセージのリカバリに使用されます。

group_replication_member_expel_timeout システム変数は、メンバーが明示されるのではなくグループに戻るための最初の 5 秒間の検出期間に加えて許可される待機期間 (最大 1 時間) を決定します。 XCom メッセージキャッシュのサイズは、メンバーが正常に戻るために必要なすべての欠落メッセージが含まれるように、この期間内の予想されるメッセージ量を参照して設定する必要があります。 MySQL 8.0.20 までは、デフォルトは 5 秒の検出期間のみですが、MySQL 8.0.21 からは、合計 10 秒間、5 秒の検出期間後の待機期間は 5 秒です。

MySQL Server の他のキャッシュおよびオブジェクトプールのサイズを考慮して、選択したキャッシュサイズ制限に十分なメモリーがシステムで使用可能であることを確認します。 デフォルト設定は 1073741824 バイト (1 GB) です。 最小設定は、MySQL 8.0.20 まで 1 GB です。 MySQL 8.0.21 からは、最小設定は 134217728 バイト (128 MB) で、使用可能なメモリー量が制限されたホストへのデプロイメントが可能になり、グループメンバーの接続の一時的な損失の頻度と期間を最小限に抑えるための適切なネットワーク接続が可能になります。 group_replication_message_cache_size を使用して設定された制限はキャッシュに格納されているデータにのみ適用され、キャッシュ構造には追加の 50 MB のメモリーが必要です。

キャッシュサイズ制限は、実行時に動的に増減できます。 キャッシュサイズ制限を小さくすると、XCom では、現在のサイズが制限を下回るまで、決定および配信された最も古いエントリが削除されます。 Group Replication Group Communication System (GCS) は、現在アクセスできないメンバーによるリカバリに必要と思われるメッセージがメッセージキャッシュから削除されたときに、警告メッセージでアラートを生成します。 メッセージキャッシュサイズのチューニングの詳細は、セクション18.6.5「XCom キャッシュ管理」 を参照してください。

group_replication_poll_spin_loops

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_poll_spin_loops では、グループ通信スレッドが通信エンジン mutex の解放を待機する回数を指定します。この回数を超えると、スレッドは追加の着信ネットワークメッセージを待機します。

group_replication_recovery_complete_at

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_complete_at では、既存のメンバーからの状態転送後にキャッシュされたトランザクションを処理する際に、分散リカバリプロセス中に適用されるポリシーを指定します。 メンバーがグループ (TRANSACTIONS_CERTIFIED) に参加する前に見逃したすべてのトランザクションを受信して認証した後、または受信、認証および適用した後 (TRANSACTIONS_APPLIED) にのみ、メンバーをオンラインとしてマークするかどうかを選択できます。

group_replication_recovery_compression_algorithm

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_compression_algorithm では、ドナーバイナリログからの状態転送用のグループレプリケーション分散リカバリ接続に許可される圧縮アルゴリズムを指定します。 使用可能なアルゴリズムは、protocol_compression_algorithms システム変数の場合と同じです。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

この設定は、クローニングをサポートするようにサーバーが設定されており (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、分散リカバリ中にリモートクローニング操作が使用されている場合は適用されません。 この状態転送方法では、クローンプラグインの clone_enable_compression 設定が適用されます。

group_replication_recovery_get_public_key

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_get_public_key は、RSA キーペアベースのパスワード交換に必要な公開キーをソースからリクエストするかどうかを指定します。 group_replication_recovery_public_key_path が有効な公開キーファイルに設定されている場合は、group_replication_recovery_get_public_key よりも優先されます。 この変数は、group_replication_recovery チャネル (group_replication_recovery_use_ssl=ON) を介した分散リカバリに SSL を使用せず、グループレプリケーションのレプリケーションユーザーアカウントが caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) で認証される場合に適用されます。 詳細は、セクション18.5.3.1.1「キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー」を参照してください。

group_replication_recovery_public_key_path

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_public_key_path では、RSA キーペアベースのパスワード交換のソースで必要な公開キーのレプリカ側コピーを含むファイルへのパス名を指定します。 ファイルは PEM 形式である必要があります。 group_replication_recovery_public_key_path が有効な公開キーファイルに設定されている場合は、group_replication_recovery_get_public_key よりも優先されます。 この変数は、group_replication_recovery チャネルを介した分散リカバリに SSL を使用しておらず (group_replication_recovery_use_ssl が OFF に設定されている場合)、Group Replication のレプリケーションユーザーアカウントが caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) または sha256_password プラグインで認証される場合に適用されます。 (sha256_password の場合、group_replication_recovery_public_key_path の設定は、MySQL が OpenSSL を使用して構築された場合にのみ適用されます。) 詳細は、セクション18.5.3.1.1「キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー」を参照してください。

group_replication_recovery_reconnect_interval

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_reconnect_interval では、分散リカバリに適したドナーがグループに見つからなかった場合の再接続試行の間隔を秒単位で指定します。

group_replication_recovery_retry_count

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_retry_count は、参加しているメンバーが分散リカバリに使用可能なドナーへの接続を試みる回数を指定します。

group_replication_recovery_ssl_ca

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_ca は、分散リカバリ接続用の信頼できる SSL 認証局のリストを含むファイルへのパスを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

このサーバーがクローニングをサポートするように設定されていて (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、group_replication_recovery_use_ssl を ON に設定している場合、Group Replication はクローン SSL オプション clone_ssl_ca の設定を group_replication_recovery_ssl_ca の設定と一致するように自動的に構成します。

group_replication_recovery_ssl_capath

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_capath は、分散リカバリ接続用の信頼できる SSL 認証局証明書を含むディレクトリへのパスを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_ssl_cert

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_cert では、分散リカバリ用のセキュアな接続を確立するために使用する SSL 証明書ファイルの名前を指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

このサーバーがクローニングをサポートするように設定されていて (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、group_replication_recovery_use_ssl を ON に設定している場合、Group Replication はクローン SSL オプション clone_ssl_cert の設定を group_replication_recovery_ssl_cert の設定と一致するように自動的に構成します。

group_replication_recovery_ssl_cipher

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_cipher では、SSL 暗号化に許可される暗号のリストを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_ssl_crl

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_crl は、証明書失効リストを含むファイルを含むディレクトリへのパスを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_ssl_crlpath

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_crlpath は、証明書失効リストを含むファイルを含むディレクトリへのパスを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_ssl_key

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_key では、セキュアな接続の確立に使用する SSL キーファイルの名前を指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

このサーバーがクローニングをサポートするように設定されていて (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、group_replication_recovery_use_ssl を ON に設定している場合、Group Replication はクローン SSL オプション clone_ssl_key の設定を group_replication_recovery_ssl_key の設定と一致するように自動的に構成します。

group_replication_recovery_ssl_verify_server_cert

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_ssl_verify_server_cert では、分散リカバリ接続でドナーによって送信された証明書のサーバー共通名の値をチェックするかどうかを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_tls_ciphersuites

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_tls_ciphersuites では、分散リカバリ接続の接続暗号化に TLSv1.3 が使用され、このサーバーインスタンスが分散リカバリ接続のクライアント (参加メンバー) である場合に、許可されている 1 つ以上の暗号スイートのコロン区切りリストを指定します。 TLSv1.3 の使用時にこのシステム変数が NULL に設定されている場合 (システム変数を設定しない場合のデフォルト)、セクション6.3.2「暗号化された接続 TLS プロトコルおよび暗号」 にリストされているように、デフォルトで有効になっている暗号スイートが許可されます。 このシステム変数が空の文字列に設定されている場合、暗号スイートは許可されないため、TLSv1.3 は使用されません。 このシステム変数は、MySQL 8.0.19 以降で使用できます。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_tls_version

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_tls_version では、このサーバーインスタンスが分散リカバリ接続のクライアント (参加メンバー) である場合に、接続暗号化に許可される TLS プロトコルのカンマ区切りリストを指定します。 指定したバージョンが連続していることを確認します (たとえば、「TLSv1,TLSv1.1,TLSv1.2」)。 このシステム変数が設定されていない場合、デフォルトの 「TLSv1,TLSv1.1,TLSv1.2,TLSv1.3」 が使用されます。 クライアント (参加メンバー) およびサーバー (ドナー) としての各分散リカバリ接続に含まれるグループメンバーは、どちらもサポートするように設定されている最高のプロトコルバージョンをネゴシエートします。 このシステム変数は、MySQL 8.0.19 から使用できます。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_recovery_use_ssl

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_use_ssl では、グループメンバー間のグループレプリケーション分散リカバリ接続で SSL を使用するかどうかを指定します。 分散リカバリのための SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

このサーバーがクローニングをサポートするように設定されている場合 (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、このオプションを ON に設定すると、グループレプリケーションでは、リモートクローニング操作およびドナーのバイナリログからの状態転送に SSL が使用されます。 このオプションを OFF に設定すると、グループレプリケーションはリモートクローニング操作に SSL を使用しません。

group_replication_recovery_zstd_compression_level

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_recovery_zstd_compression_level では、zstd 圧縮アルゴリズムを使用するグループレプリケーション分散リカバリ接続に使用する圧縮レベルを指定します。 許可されるレベルは 1 から 22 で、大きい値は圧縮レベルの増加を示します。 デフォルトの zstd 圧縮レベルは 3 です。 zstd 圧縮を使用しない分散リカバリ接続の場合、この変数は無効です。

詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

group_replication_single_primary_mode

このシステム変数は、グループ全体の構成設定です。 値の変更を有効にするには、すべてのグループメンバーで同じ値を持つ必要があり、グループレプリケーションの実行中は変更できず、グループ (group_replication_bootstrap_group=ON を使用したサーバーによるブートストラップ) を完全に再起動する必要があります。 MySQL 8.0.16 から、group_replication_switch_to_single_primary_mode() および group_replication_switch_to_multi_primary_mode() UDF を使用して、グループの実行中にこのシステム変数の値を変更できます。 詳細は、セクション18.4.1.2「グループモードの変更」を参照してください。

group_replication_single_primary_mode は、読取り/書込みワークロードを処理する単一のサーバーを自動的に選択するようにグループに指示します。 このサーバーは PRIMARY で、その他はすべて SECONDARIES です。

group_replication_ssl_mode

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_ssl_mode は、グループレプリケーションメンバー間のグループ通信接続のセキュリティ状態を設定します。 使用可能な値は次のとおりです:

グループ通信用の SSL の構成の詳細は、セクション18.5.2「Secure Socket Layer (SSL) を使用したグループ通信接続の保護」 を参照してください。

group_replication_start_on_boot

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_start_on_boot では、サーバーの起動時にグループレプリケーションを自動的に起動するか (ON) 起動しないか (OFF) を指定します。 このオプションを ON に設定すると、リモートクローニング操作を分散リカバリに使用した後、グループレプリケーションが自動的に再起動されます。

サーバーの起動時に Group Replication を自動的に起動するには、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用して、分散リカバリのユーザー資格証明をサーバー上のレプリケーションメタデータリポジトリに格納する必要があります。 ユーザー資格証明をメモリーにのみ格納する START GROUP_REPLICATION ステートメントでユーザー資格証明を指定する場合は、group_replication_start_on_boot が OFF に設定されていることを確認します。

group_replication_tls_source

このシステム変数の値は、Group Replication の実行中に変更できますが、変更はグループメンバーで Group Replication を停止して再起動した後にのみ有効になります。

group_replication_tls_source は、Group Replication の TLS 材料のソースを指定します。

group_replication_transaction_size_limit

このシステム変数は、すべてのグループメンバーで同じ値を持つ必要があります。 このシステム変数の値は、Group Replication の実行中に変更できます。 変更はグループメンバーに対して即時に有効になり、そのメンバーで開始された次のトランザクションから適用されます。 このプロセス中、システム変数の値はグループメンバー間で異なってもかまいませんが、一部のトランザクションは拒否される可能性があります。

group_replication_transaction_size_limit は、レプリケーショングループが受け入れる最大トランザクションサイズをバイト単位で構成します。 このサイズより大きいトランザクションは受信側メンバーによってロールバックされ、グループにブロードキャストされません。 大規模なトランザクションでは、システムの速度が低下する原因となる可能性のあるメモリー割当て、または大規模なトランザクションの処理がビジー状態であるためにメンバーに障害が発生した疑いがあるネットワーク帯域幅消費の観点から、レプリケーショングループの問題が発生する可能性があります。

このシステム変数が 0 に設定されている場合、グループが受け入れるトランザクションのサイズに制限はありません。 MySQL 8.0 からは、このシステム変数のデフォルト設定は 150000000 バイト (約 143 MB) です。 トランザクションの処理にかかる時間はそのサイズに比例することに注意して、グループが許容する必要がある最大メッセージサイズに応じて、このシステム変数の値を調整します。 group_replication_transaction_size_limit の値は、すべてのグループメンバーで同じである必要があります。 大規模トランザクションの軽減戦略の詳細は、セクション18.9.2「グループレプリケーションの制限事項」 を参照してください。

group_replication_unreachable_majority_timeout

このシステム変数の値は、Group Replication の実行中に変更でき、変更はただちに有効になります。 システム変数の現在の値は、動作が必要であることを意味する問題が発生したときに読み取られます。

group_replication_unreachable_majority_timeout では、ネットワークパーティションが不足し、大部分のメンバーがグループを離れるまで待機できないメンバーの秒数を指定します。 5 つのサーバー (S1、S2、S3、S4、S5) のグループでは、(S1、S2) と (S3、S4、S5) の間に切断がある場合、ネットワークパーティションがあります。 最初のグループ (S1、S2) は、半分を超えるグループにコンタクトできないため、少数民族になりました。 大多数のグループ (S3、S4、S5) が実行されている間、少数民族グループはネットワークの再接続を指定された時間待機します。 このシナリオの詳細は、セクション18.4.4「ネットワークパーティション化」 を参照してください。

デフォルトでは、group_replication_unreachable_majority_timeout は 0 に設定されています。これは、ネットワークパーティションのために少数民族で自身を検索するメンバーが、グループから離れるまで永久に待機することを意味します。 タイムアウトを設定した場合、指定した時間が経過すると、その少数民族によって処理されたすべての保留中のトランザクションがロールバックされ、少数パーティション内のサーバーは ERROR 状態に移行します。 メンバーの group_replication_autorejoin_tries システム変数が自動再結合の試行回数を指定するように設定されている場合、スーパー読取り専用モードでは、指定された回数だけグループへの再結合が試行されます。 メンバーに自動再結合の試行が指定されていない場合、または指定された試行回数を使い果たした場合は、システム変数 group_replication_exit_state_action で指定されたアクションに従います。

このオプションの使用方法の詳細は、セクション18.6.6.2「使用できない大多数のタイムアウト」 を参照してください。