グループレプリケーション障害検出メカニズムは、グループと通信しなくなったグループメンバーを識別し、障害が発生した可能性があると思われる場合に明示するように設計されています。 障害検出メカニズムを使用すると、グループに正しく機能するメンバーの大部分が含まれ、そのためクライアントからのリクエストが正しく処理される可能性が高くなります。

通常、すべてのグループメンバーは、他のすべてのグループメンバーと定期的にメッセージを交換します。 グループメンバーが特定のフェローメンバーからのメッセージを 5 秒間受信しない場合、この検出期間が終了すると、フェローメンバーの疑いが生じます。 疑わしいメンバーがタイムアウトすると、疑わしいメンバーは失敗したとみなされ、グループから削除されます。 削除されたメンバーは、他のメンバーに表示されるメンバーシップリストから削除されますが、グループから削除されたことは認識されないため、オンラインとして表示され、他のメンバーは使用不可として表示されます。 メンバーが実際に失敗しておらず (たとえば、一時的なネットワークの問題のために切断されたばかりのため)、他のメンバーとの通信を再開できる場合は、グループから削除された情報を含むビューを受信します。

これらの状況に対するグループメンバーのレスポンス (失敗したメンバー自体を含む) は、プロセスのいくつかのポイントで構成できます。 デフォルトでは、メンバーに障害が発生した疑いがある場合、次の動作が発生します:

このセクションで説明する Group Replication 構成オプションを使用すると、システム要件および優先順位に合せて、これらの動作を永続的または一時的に変更できます。 低速なネットワークまたはマシン、予期しない一時的な停止率の高いネットワーク、または計画的なネットワーク停止が原因で不要な削除が発生した場合は、expel timeout および auto-rejoin の試行を増やすことを検討してください。 MySQL 8.0.21 からは、この方向にデフォルト設定が変更され、これらの状況でメンバーを解放するためにオペレータの介入が必要になる頻度が削減されました。 メンバーは前述のデフォルトの動作のいずれかを実行していますが、書込みを受け入れませんが、メンバーがクライアントと通信している場合は、時間の経過とともに失効した読取りの可能性が高くなり、読取りを行うことができます。 失効した読取りの回避は、演算子の介入を回避するよりも優先度が高い場合は、expel timeout および auto-rejoin の試行を減らすか、ゼロに設定することを検討してください。

障害が発生していないメンバーは、ネットワークパーティションのためにレプリケーショングループの一部 (すべてではない) との接続を失う可能性があります。 たとえば、5 つのサーバー (S1、S2、S3、S4、S5) のグループでは、(S1、S2) と (S3、S4、S5) の間に切断がある場合、ネットワークパーティションがあります。 最初のグループ (S1、S2) は、半分を超えるグループにコンタクトできないため、少数民族になりました。 少数民族グループのメンバーによって処理されるトランザクションはブロックされます。これは、グループの大部分にアクセスできないため、グループはクォーラムを達成できないためです。 このシナリオの詳細は、セクション18.4.4「ネットワークパーティション化」 を参照してください。 この場合、デフォルトの動作では、少数民族と大多数のメンバーがグループに残り、(少数民族のメンバーでブロックされていても) トランザクションの受入れを続行し、オペレータの介入を待機します。 この動作も構成可能です。

関連する設定をサポートしていない古い MySQL Server リリースのグループメンバー、または異なるデフォルトのリリースのグループメンバーは、前述のデフォルトの動作に従って自身および他のグループメンバーに作用します。 たとえば、group_replication_member_expel_timeout システム変数をサポートしていないメンバーは、期限切れの疑いが検出されるとすぐに他のメンバーを削除し、システム変数をサポートしており、タイムアウトが長く設定されている場合でも、この削除は他のメンバーによって受け入れられます。