MySQL 8.0.13 から使用可能な group_replication_member_expel_timeout システム変数を使用すると、疑わしいメンバーの作成と削除の間に時間を追加できます。 疑わしいのは、セクション18.1.4.2「障害検出」 で説明されているように、あるサーバーが別のサーバーからメッセージを受信しない場合です。
グループレプリケーショングループメンバーが別のメンバー (またはそれ自体) の疑いを作成する前に、最初の 5 秒の検出期間があります。 グループメンバーは、その別のメンバーの疑い (またはそれ自体の疑い) がタイムアウトしたときに削除されます。 それよりも短い時間が経過すると、削除メカニズムが削除を検出して実装する前に経過する可能性があります。group_replication_member_expel_timeout では、expel timeout と呼ばれる、疑わしいメンバーの作成と疑わしいメンバーの削除の間にグループメンバーが待機する時間を秒単位で指定します。 サスペクトメンバーは、この待機期間中は UNREACHABLE としてリストされますが、グループメンバーシップリストからは削除されません。
疑わしいメンバーが待機期間の終了時にタイムアウトする前に再度アクティブになった場合、メンバーは XCom メッセージキャッシュ内の残りのグループメンバーによってバッファされたすべてのメッセージを適用し、オペレータの介入なしで
ONLINE状態になります。 この状況では、メンバーは同じインカネーションとしてグループによって考慮されます。疑わしいメンバーがアクティブになるのは、疑わしいメンバーがタイムアウトして通信を再開できる場合のみで、削除されたビューを受信し、その時点で削除されたことを認識します。 MySQL 8.0.16 から使用可能な
group_replication_autorejoin_triesシステム変数を使用して、この時点でメンバーがグループへの再参加を自動的に試行するようにできます。 MySQL 8.0.21 からは、この機能はデフォルトでアクティブ化され、メンバーは 3 回の自動再結合を試行します。 自動再結合プロシージャが成功しなかった場合、または試行されなかった場合、削除されたメンバーはgroup_replication_exit_state_actionで指定された終了アクションに従います。
メンバーを削除するまでの待機期間は、以前にグループ内でアクティブになっていたメンバーにのみ適用されます。 グループ内でアクティブになっていなかった非メンバーは、この待機期間を取得せず、最初の検出期間の後に削除されます。これは、参加に時間がかかりすぎるためです。
group_replication_member_expel_timeout が 0 に設定されている場合、待機期間はなく、疑わしいメンバーは 5 秒間の検出期間が終了した直後に削除する責任があります。 この設定は、MySQL 8.0.20 までのデフォルトです。 これは、group_replication_member_expel_timeout システム変数をサポートしていない MySQL Server バージョンのグループメンバーの動作でもあります。 MySQL 8.0.21 からは、値はデフォルトで 5 に設定されます。つまり、疑わしいメンバーは、5 秒間の検出期間の 5 秒後に強制的に実行されます。 グループのすべてのメンバーが group_replication_member_expel_timeout に対して同じ設定を持つことは必須ではありませんが、予期しない実行を回避するためにお薦めします。 すべてのメンバーは、それ自体を含む他のメンバーの疑わしいものを作成できるため、有効な明示タイムアウトは、設定が最も小さいメンバーの疑わしいタイムアウトです。
次のシナリオでは、group_replication_member_expel_timeout の値をデフォルトから増やすことを検討してください:
ネットワークの速度が遅く、強制終了までのデフォルトの 5 秒または 10 秒の長さが不足しているため、グループメンバーは常に少なくとも 1 つのメッセージを交換できません。
ネットワークに一時的な停止があり、この時点で不要な削除およびプライマリメンバーの変更を回避する必要がある場合があります。
ネットワークは直接制御されておらず、オペレータの介入の必要性を最小限に抑える必要があります。
一時的なネットワーク停止が予想され、このために一部またはすべてのメンバーを削除しない場合。
個々のマシンで速度が低下しており、グループから削除しない場合。
最大 3600 秒 (1 時間) までの指数タイムアウトを指定できます。 XCom メッセージキャッシュが、指定した期間内の予想されるメッセージ量に最初の 5 秒の検出期間を加えて十分に大きいことを確認することが重要です。そうしないと、メンバーは再接続できません。 group_replication_message_cache_size システム変数を使用して、キャッシュサイズ制限を調整できます。 詳細は、セクション18.6.5「XCom キャッシュ管理」を参照してください。
グループ内のいずれかのメンバーが現在疑わしい場合、グループメンバーシップを再構成することはできません (メンバーを追加または削除するか、新しいリーダーを選択します)。 1 つ以上のメンバーが疑わしいときにグループメンバーシップの変更を実装する必要があり、疑わしいメンバーをグループに残す場合は、可能であれば、メンバーを再度アクティブにするために必要なアクションを実行します。 メンバーを再度アクティブにできず、グループから削除する場合は、疑わしいメンバーをただちに強制的にタイムアウトさせることができます。 これを行うには、アクティブなメンバーの group_replication_member_expel_timeout の値を、疑いが作成されてからすでに経過した時間より小さい値に変更します。 疑わしいメンバーはすぐに強制の責任を負います。
レプリケーショングループメンバーが予期せず停止し、すぐに再起動された場合 (たとえば、mysqld_safe で起動されたため)、group_replication_start_on_boot=on が設定されている場合は、グループへの再参加が自動的に試行されます。 この状況では、メンバーの前のインカネーションがグループから削除される前に、再起動および再結合の試行が行われる可能性があります。その場合、メンバーは再結合できません。 MySQL 8.0.19 からは、グループレプリケーションはグループ通信システム (GCS) 機能を自動的に使用して、再試行ごとに 5 秒間隔でメンバーの再結合試行を 10 回再試行します。 これはほとんどのケースに対応し、前のインカネーションをグループから削除してメンバーを再結合できるようにするのに十分な時間を確保する必要があります。 メンバーが削除される前に、より長い待機期間を指定するように group_replication_member_expel_timeout システム変数が設定されている場合でも、自動再結合の試行は成功しない可能性があります。
group_replication_member_expel_timeout システム変数が使用できない場合に不要な削除を回避するための代替軽減戦略については、セクション18.9.2「グループレプリケーションの制限事項」 を参照してください。