このページは機械翻訳したものです。

18.1.4.1 グループメンバーシップ

MySQL Group Replication では、一連のサーバーがレプリケーショングループを形成します。 グループには UUID の形式をとる名前があります。 このグループは動的であり、サーバーはいつでも (自発的または無関係に) 離脱して参加できます。 サーバーが参加または退出するたびに、グループ自体が調整されます。

サーバーがグループに参加すると、既存のサーバーから欠落している状態がフェッチされ、自動的に最新の状態になります。 サーバーがグループから離れると (たとえば、メンテナンスのために停止された場合)、残りのサーバーは自動的にグループを離れて再構成したことに気付きます。

グループレプリケーションには、オンラインでグループに参加しているサーバーを定義するグループメンバーシップサービスがあります。 オンラインサーバーのリストは view と呼ばれます。 グループ内のすべてのサーバーには、特定の時点でグループにアクティブに参加しているサーバーの一貫したビューがあります。

グループメンバーは、トランザクションのコミットのみでなく、現在のビューでも一致する必要があります。 既存のメンバーが新しいサーバーをグループの一部にする必要があることに同意すると、そのサーバーを統合するようにグループが再構成され、ビューの変更がトリガーされます。 サーバーが自発的にグループから離れるかどうかにかかわらず、グループはその構成を動的に再配置し、ビューの変更がトリガーされます。

メンバーが自発的にグループから離れる場合、最初に動的グループ再構成を開始し、その間、すべてのメンバーはサーバーから離れることなく新しいビューに同意する必要があります。 ただし、予期せず停止した場合やネットワーク接続が停止している場合などに、メンバーがグループを離れると、再構成を開始できません。 この状況では、グループレプリケーションの障害検出メカニズムは、メンバーが残っている短期間を認識し、障害が発生したメンバーのないグループの再構成を提案します。 自発的に退職するメンバーと同様に、再構成にはグループ内の大部分のサーバーからの同意が必要です。 ただし、大部分のサーバーがオンラインにならないようにパーティション化されているなどの理由で、グループがアグリーメントに到達できない場合、システムは構成を動的に変更できず、スプリットブレインの状況を防ぐためにブロックされます。 この状況では、管理者の介入が必要です。

メンバーが短時間オフラインになってから、障害検出メカニズムによって障害が検出される前、およびグループが再構成されてメンバーが削除される前に、グループへの再参加を再試行できます。 この場合、再参加メンバーは以前の状態を忘れますが、他のメンバーがその前の状態を意図したメッセージを送信すると、データの不整合などの問題が発生する可能性があります。 この状況のメンバーが XCom コンセンサスプロトコルに参加している場合、障害の前後に異なる決定を行うことで、XCom が同じコンセンサスラウンドに対して異なる値を配信する可能性があります。

この可能性に対処するために、MySQL 5.7.22 および MySQL 8.0 では、グループレプリケーションは、(同じアドレスとポート番号を持つ) 古いインカネーションがメンバーとしてリストされているときに、同じサーバーの新しいインカネーションがグループに参加しようとしている状況をチェックします。 新しいインカネーションは、再構成によって古いインカネーションを削除できるようになるまで、グループへの参加をブロックされます。 メンバーが削除される前にグループに再接続できるように、待機期間が group_replication_member_expel_timeout システム変数によって追加されている場合、疑わしいメンバーが疑わしいタイムアウトの前にグループに再接続すると、疑わしいメンバーが現在のインカネーションとして再度アクティブになる可能性があります。 メンバーが expel タイムアウトを超えてグループから削除された場合、または STOP GROUP_REPLICATION ステートメントまたはサーバー障害によってサーバーでグループレプリケーションが停止された場合は、新しいインカネーションとして再結合する必要があります。