参加メンバーが分散リカバリ中に状態転送のためにオンラインの既存メンバーに接続すると、参加メンバーは接続のクライアントとして機能し、既存のメンバーはサーバーとして機能します。 ドナーバイナリログからの状態転送がこの接続で (非同期レプリケーションチャネル group_replication_recovery を使用して) 進行中の場合、参加メンバーはレプリカとして機能し、既存のメンバーはソースとして機能します。 リモートクローニング操作がこの接続で進行中の場合、参加メンバーは受信者として機能し、既存のメンバーはドナーとして機能します。 グループレプリケーションコンテキスト外のロールに適用される構成設定は、グループレプリケーション固有の構成設定または動作によってオーバーライドされないかぎり、グループレプリケーションにも適用できます。
既存のメンバーが分散リカバリのために参加メンバーに提供する接続は、グループのオンラインメンバー間の通信にグループレプリケーションで使用される接続と同じではありません。
リモート XCom インスタンス間の TCP 通信用のグループレプリケーション (XCom、Paxos バリアント) のためにグループ通信エンジンによって使用される接続は、
group_replication_local_addressシステム変数によって指定されます。 この接続は、オンラインメンバー間の TCP/IP メッセージに使用されます。 ローカルインスタンスとの通信は、共有メモリーを使用して入力チャネルを介して行われます。分散リカバリの場合、MySQL 8.0.20 まで、グループメンバーは、MySQL Server
hostnameおよびportシステム変数で指定された、結合メンバーへの標準 SQL クライアント接続を提供します。report_portシステム変数で代替ポート番号が指定されている場合は、かわりにそのポート番号が使用されます。MySQL 8.0.21 から、グループメンバーは分散リカバリエンドポイントの代替リストをメンバー参加専用クライアント接続として通知できるため、メンバーの通常のクライアントユーザーによる接続とは別に分散リカバリトラフィックを制御できます。 このリストは
group_replication_advertise_recovery_endpointsシステム変数を使用して指定し、メンバーはグループに参加するときに分散リカバリエンドポイントのリストをグループに送信します。 デフォルトでは、メンバーは以前のリリースと同様に標準 SQL クライアント接続を引き続き提供します。
結合メンバーが、MySQL Server hostname システム変数で定義されたホスト名を使用して他のメンバーを正しく識別できない場合、分散リカバリは失敗する可能性があります。 MySQL を実行しているオペレーティングシステムでは、DNS またはローカル設定を使用して、一意のホスト名を適切に構成することをお薦めします。 サーバーが SQL クライアント接続に使用しているホスト名は、「パフォーマンススキーマ」テーブル replication_group_members の Member_host カラムで確認できます。 複数のグループメンバーがオペレーティングシステムによって設定されたデフォルトのホスト名を外部化する場合、参加メンバーが正しいメンバーアドレスに解決せず、分散リカバリのために接続できない可能性があります。 この状況では、MySQL Server report_host システム変数を使用して、各サーバーによって外部化される一意のホスト名を構成できます。
結合メンバーが分散リカバリ用の接続を確立するステップは、次のとおりです:
メンバーがグループに参加すると、
group_replication_group_seedsシステム変数のリストに含まれているシードメンバーのいずれかに接続され、最初はそのリストで指定されているgroup_replication_local_address接続が使用されます。 シードメンバーは、グループのサブセットである場合があります。この接続を介して、シードメンバーはグループレプリケーションメンバーシップサービスを使用して、グループ内のオンラインのすべてのメンバーのリストをビューの形式で結合メンバーに提供します。 メンバーシップ情報には、分散リカバリのために各メンバーが提供する分散リカバリエンドポイントまたは標準 SQL クライアント接続の詳細が含まれます。
参加メンバーは、セクション18.4.3.4「分散リカバリのフォルトトレランス」 で説明されている動作に従って、分散リカバリのドナーとなる適切なグループメンバーをこのリストから選択します。
その後、参加メンバーは、ドナーによって通知された分散リカバリエンドポイントを使用してドナーへの接続を試行し、それぞれをリストに指定された順序で試行します。 ドナーがエンドポイントを提供しない場合、参加メンバーはドナー標準 SQL クライアント接続を使用して接続を試みます。 接続の SSL 要件は、セクション18.4.3.1.4「分散リカバリの SSL および認証」 で説明されている
group_replication_recovery_ssl_*オプションで指定されているとおりです。参加メンバーが選択したドナーに接続できない場合、セクション18.4.3.4「分散リカバリのフォルトトレランス」 で説明されている動作に従って、他の適切なドナーで再試行します。 参加メンバーが接続を確立せずに通知されたエンドポイントのリストを使い果たした場合、ドナー標準 SQL クライアント接続にフォールバックするのではなく、別のドナーに切り替えることに注意してください。
参加メンバーがドナーとの分散リカバリ接続を確立すると、セクション18.4.3「分散リカバリ」 で説明されているように、その接続が状態転送に使用されます。 使用される接続のホストとポートは、参加メンバーログに表示されます。 リモートクローニング操作を使用する場合、参加メンバーが操作の最後に再起動すると、バイナリログからの状態転送用に新しいドナーとの接続が確立されます。 これは、リモートクローニング操作に使用される元のドナーとは異なるメンバーへの接続であるか、元のドナーへの別の接続である可能性があります。 いずれの場合も、分散リカバリプロセスは元のドナーと同じ方法で続行されます。
分散リカバリエンドポイントとして group_replication_advertise_recovery_endpoints システム変数によって提供される IP アドレスは、MySQL Server 用に構成する必要はありません (つまり、admin_address システム変数または bind_address システム変数のリストで指定する必要はありません)。 これらはサーバーに割り当てる必要があります。 使用するホスト名は、ローカル IP アドレスに解決される必要があります。 IPv4 および IPv6 アドレスを使用できます。
分散リカバリエンドポイントに指定するポートは、MySQL Server 用に構成する必要があるため、port、report_port または admin_port システム変数で指定する必要があります。 サーバーは、これらのポートで TCP/IP 接続をリスニングする必要があります。 admin_port を指定する場合、分散リカバリのレプリケーションユーザーが接続するには SERVICE_CONNECTION_ADMIN 権限が必要です。 admin_port を選択すると、分散リカバリ接続が通常の MySQL クライアント接続とは別に維持されます。
メンバーの結合では、リストで指定された順序で各エンドポイントが順に試行されます。 group_replication_advertise_recovery_endpoints がエンドポイントのリストではなく DEFAULT に設定されている場合、標準 SQL クライアント接続が提供されます。 標準 SQL クライアント接続は分散リカバリエンドポイントのリストに自動的には含まれず、エンドポイントのドナーリストが接続なしで使い果たされた場合、フォールバックとして提供されないことに注意してください。 標準 SQL クライアント接続を多数の分散リカバリエンドポイントのいずれかとして提供する場合は、group_replication_advertise_recovery_endpoints で指定されたリストに明示的に含める必要があります。 接続の最後の手段として機能するように、最後の場所に配置できます。
グループメンバー分散リカバリエンドポイント (エンドポイントが指定されていない場合は標準 SQL クライアント接続) は、group_replication_ip_allowlist (MySQL 8.0.22) または group_replication_ip_whitelist システム変数で指定されたグループレプリケーション許可リストに追加する必要はありません。 allowlist は、メンバーごとに group_replication_local_address によって指定されたアドレスに対してのみ使用されます。 分散リカバリのためにアドレスを取得するには、参加メンバーは allowlist によって許可されたグループへの初期接続を持っている必要があります。
リストした分散リカバリエンドポイントは、システム変数が設定されたとき、および START GROUP_REPLICATION ステートメントが発行されたときに検証されます。 リストを正しく解析できない場合、またはサーバーがリスニングしていないためにホスト上でいずれかのエンドポイントにアクセスできない場合、Group Replication はエラーをログに記録し、起動しません。
MySQL 8.0.18 から、ドナーバイナリログからの状態転送によって、分散リカバリの圧縮をオプションで構成できます。 圧縮は、ネットワーク帯域幅が制限され、ドナーが多数のトランザクションを参加メンバーに転送する必要がある分散リカバリに役立ちます。 group_replication_recovery_compression_algorithm および group_replication_recovery_zstd_compression_level システム変数は、ドナーのバイナリログから状態転送を実行するときに使用される、許可される圧縮アルゴリズムと zstd 圧縮レベルを構成します。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。
これらの圧縮設定は、リモートクローニング操作には適用されないことに注意してください。 リモートクローニング操作を分散リカバリに使用する場合、クローンプラグインの clone_enable_compression 設定が適用されます。
分散リカバリでは、グループレプリケーションがメンバー間の直接レプリケーションチャネルを確立できるように、適切な権限を持つレプリケーションユーザーが必要です。 レプリケーションユーザーには、リモートクローニング操作のためにドナーでクローンユーザーとして機能する適切な権限も必要です。 すべてのグループメンバーで分散リカバリに同じレプリケーションユーザーを使用する必要があります。 このレプリケーションユーザーを設定する手順は、セクション18.2.1.3「分散リカバリのユーザー資格証明」 を参照してください。 レプリケーションユーザー資格証明を保護する手順は、セクション18.5.3.1「分散リカバリのためのセキュアなユーザー資格証明」 を参照してください。
分散リカバリ用の SSL は、サーバーの SSL 設定および group_replication_ssl_mode システム変数によって決定される通常のグループ通信用の SSL とは別に構成されます。 分散リカバリ接続の場合、専用のグループレプリケーション分散リカバリ SSL システム変数を使用して、分散リカバリ専用の証明書および暗号の使用を構成できます。
デフォルトでは、分散リカバリ接続に SSL は使用されません。 これをアクティブ化するには、セクション18.5.3「分散リカバリ接続の保護」 の説明に従って、group_replication_recovery_use_ssl=ON を設定し、Group Replication 分散リカバリ SSL システム変数を構成します。 SSL を使用するように設定されたレプリケーションユーザーが必要です。
分散リカバリが SSL を使用するように構成されている場合、グループレプリケーションは、リモートクローニング操作およびドナーのバイナリログからの状態転送にこの設定を適用します。 Group Replication は、クローン SSL オプション (clone_ssl_ca、clone_ssl_cert および clone_ssl_key) の設定を、対応する Group Replication 分散リカバリオプション (group_replication_recovery_ssl_ca、group_replication_recovery_ssl_cert および group_replication_recovery_ssl_key) の設定と一致するように自動的に構成します。
分散リカバリに SSL を使用せず (group_replication_recovery_use_ssl が OFF に設定されている)、Group Replication のレプリケーションユーザーアカウントが caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) または sha256_password プラグインで認証される場合、RSA キーペアがパスワード交換に使用されます。 この場合、セクション18.5.3.1.1「キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー」 で説明されているように、group_replication_recovery_public_key_path システム変数を使用して RSA 公開キーファイルを指定するか、group_replication_recovery_get_public_key システム変数を使用してソースから公開キーをリクエストします。