レプリケートする必要がある変更が発生するたびに、グループはコンセンサスを達成する必要があります。 これは通常のトランザクションの場合ですが、グループメンバーシップの変更およびグループの一貫性を維持する一部の内部メッセージングにも必要です。 コンセンサスでは、グループメンバーの大部分が特定の決定に同意する必要があります。 大部分のグループメンバーが失われると、大部分またはクォーラムを保護できないため、グループは進行できず、ブロックされます。
複数の標準的な障害が発生するとクォーラムが失われ、大部分のサーバーがグループから突然削除される可能性があります。 たとえば、5 つのサーバーのグループでは、それらの 3 つが一度にサイレントになった場合、大部分が危険にさらされるため、クォーラムを達成できません。 実際、残りの 2 つは、他の 3 つのサーバーがクラッシュしたかどうか、またはネットワークパーティションがこれら 2 つのみを分離しているため、グループを自動的に再構成できません。
一方、サーバーが自発的にグループを終了した場合は、再構成する必要があることをグループに指示します。 これは実際には、離れるサーバーが他のサーバーに離れることを通知することを意味します。 つまり、他のメンバーはグループを適切に再構成でき、メンバーシップの一貫性が維持され、大部分が再計算されます。 たとえば、3 つのサーバーが一度に残る 5 つのサーバーの前述のシナリオでは、3 つのサーバーが 1 つずつ離脱していることをグループに警告した場合、メンバーシップは 5 から 2 に調整でき、同時にクォーラムを保護できます。
クォーラムの損失は、それ自体が不正な計画の副作用です。 予想される障害の数 (連続しているか、一度にすべて発生しているか、散発的であるかに関係なく) のグループサイズを計画します。
次のセクションでは、グループ内のサーバーによって定足数が自動的に実現されないようにシステムがパーティション化された場合の対処方法について説明します。
過半数の損失後にグループから除外されたプライマリには、新しいグループに含まれていない追加のトランザクションが含まれる場合があります。 これが発生した場合、グループから除外されたメンバーを追加しなおそうとすると、「このメンバーには、グループに存在するトランザクションよりも多くの実行済トランザクションがあります」というメッセージが表示されてエラーが発生します。
replication_group_members パフォーマンススキーマテーブルには、このサーバーの観点から見た現在のビューの各サーバーのステータスが表示されます。 システムがパーティション化に実行されない時間の大部分であるため、テーブルにはグループ内のすべてのサーバー間で一貫性のある情報が表示されます。 つまり、このテーブルの各サーバーのステータスは、現在のビューのすべてによって一致します。 ただし、ネットワークのパーティション化があり、クォーラムが失われた場合は、接続できないサーバーのステータス UNREACHABLE がテーブルに表示されます。 この情報は、Group Replication に組み込まれているローカル障害検出プログラムによってエクスポートされます。
このタイプのネットワークパーティションを理解するために、次のセクションでは、最初に 5 つのサーバーが正常に連携し、2 つのサーバーのみがオンラインになった後にグループに対して行われる変更のシナリオについて説明します。 シナリオをの図に示します。
そのため、これらの 5 つのサーバーを含むグループが存在するとします:
メンバー識別子
199b2df7-4aaf-11e6-bb16-28b2bd168d07を持つサーバー s1メンバー識別子
199bb88e-4aaf-11e6-babe-28b2bd168d07を持つサーバー s2メンバー識別子
1999b9fb-4aaf-11e6-bb54-28b2bd168d07を持つサーバー s3メンバー識別子
19ab72fc-4aaf-11e6-bb51-28b2bd168d07を持つサーバー s4メンバー識別子
19b33846-4aaf-11e6-ba81-28b2bd168d07を持つサーバー s5
最初はグループは正常に実行されており、サーバーはお互いに通信しています。 これを確認するには、s1 にログインし、その replication_group_members パフォーマンススキーマテーブルを参照します。 例:
mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+-------------+
| MEMBER_ID | MEMBER_STATE |-MEMBER_ROLE |
+--------------------------------------+--------------+-------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE | SECONDARY |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | PRIMARY |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | SECONDARY |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE | SECONDARY |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE | SECONDARY |
+--------------------------------------+--------------+-------------+
ただし、後で致命的な障害が発生し、サーバー s3、s4 および s5 が予期せず停止します。 この数秒後、s1 の replication_group_members テーブルを再度参照すると、まだオンラインであることが示されますが、他のいくつかのメンバーはオンラインではありません。 実際には、次に示すように、UNREACHABLE としてマークされます。 さらに、大部分が失われたため、システム自体を再構成してメンバーシップを変更できませんでした。
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE |
+--------------------------------------+--------------+このテーブルは、大部分のサーバーにアクセスできないため、s1 が外部介入なしで進行できないグループになったことを示しています。 この場合、このセクションで説明するように、システムを続行できるようにグループメンバーシップリストをリセットする必要があります。 または、s1 および s2 でのグループレプリケーションの停止 (または完全に s1 および s2) を選択し、s3、s4 および s5 で発生したことを確認してから、グループレプリケーション (またはサーバー) を再起動することもできます。
グループレプリケーションを使用すると、特定の構成を強制することでグループメンバーシップリストをリセットできます。 たとえば、s1 および s2 のみがオンラインのサーバーである前述の場合、s1 および s2 のみで構成されるメンバーシップ構成を強制することを選択できます。 これには、s1 および s2 に関する一部の情報を確認してから、group_replication_force_members 変数を使用する必要があります。
s1 および s2 がグループに残されている唯一のサーバーである状況に戻るとします。 サーバー s3、s4 および s5 が予期せずグループから退出しました。 サーバー s1 および s2 を続行するには、s1 および s2 のみを含むメンバーシップ構成を強制します。
この手順では group_replication_force_members を使用するため、最後のリゾート処置とみなすようにしてください。 クォーラムの損失をオーバーライドする場合にのみ、十分に注意して使用する必要があります。 誤用された場合は、人工的なスプリットブレインシナリオを作成するか、システム全体を完全にブロックする可能性があります。
システムがブロックされ、現在の構成が次のようになっていることを思い出してください (s1 のローカル障害検出で認識されます):
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE |
+--------------------------------------+--------------+最初に行うことは、s1 および s2 のローカルアドレス (グループ通信識別子) を確認することです。 s1 および s2 にログインし、その情報を次のように取得します。
mysql> SELECT @@group_replication_local_address;
s1 (127.0.0.1:10000) および s2 (127.0.0.1:10001) のグループ通信アドレスがわかったら、いずれかのサーバーでそれを使用して新しいメンバーシップ構成を注入し、クォーラムを失った既存の構成をオーバーライドできます。 s1 でこれを行うには:
mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";
これにより、別の構成が強制され、グループのブロックが解除されます。 この変更後にグループメンバーシップを確認するには、s1 と s2 の両方で replication_group_members をチェックします。 s1 では最初。
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE |
+--------------------------------------+--------------+次に、s2 で行います。
mysql> SELECT * FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE |
+--------------------------------------+--------------+新しいメンバーシップ構成を強制する場合は、グループから強制的に除外されるすべてのサーバーが実際に停止されていることを確認します。 前述のシナリオでは、s3、s4 および s5 に実際にアクセスできないが、かわりにオンラインの場合、独自の機能パーティションを形成している可能性があります (5 つのうち 3 つであるため、大部分があります)。 その場合、s1 および s2 を使用してグループメンバーシップリストを強制すると、人工的なスプリットブレイン状況が発生する可能性があります。 したがって、新しいメンバーシップ構成を強制的に実行する前に、除外するサーバーが実際に停止されていることを確認し、停止されていない場合は続行する前に停止することが重要です。
group_replication_force_members システム変数を使用して新しいグループメンバーシップを強制し、グループのブロックを解除した後、必ずシステム変数をクリアしてください。START GROUP_REPLICATION ステートメントを発行するには、group_replication_force_members が空である必要があります。