Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb
HTML Download (TGZ) - 10.0Mb
HTML Download (Zip) - 10.1Mb


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

18.1.4.2 障害検出

Group Replication には、障害検出メカニズムが含まれています。このメカニズムを使用すると、どのサーバーがサイレントで、どのサーバーが停止していると想定されているかを検出してレポートできます。 高レベルでは、障害検出機能は、どのサーバーが停止する可能性があるか (疑わしい) に関する情報を提供する分散サービスです。 疑いは、サーバーがミュートされるとトリガーされます。 指定した期間中にサーバー A がサーバー B からメッセージを受信しないと、タイムアウトが発生し、疑いが発生します。 その後、グループが疑いが真であることに同意した場合、グループは特定のサーバーに実際に障害が発生したと判断します。 つまり、グループ内の残りのメンバーは、調整された決定を受けて特定のメンバーを明示します。

サーバーがグループの他の部分から分離されると、他のすべてのサーバーで障害が発生している可能性があります。 グループとのアグリーメントを保護できません (クォーラムを保護できないため)。疑いはありません。 この方法でサーバーをグループから分離すると、ローカルトランザクションを実行できなくなります。

ネットワークが不安定であり、メンバーが異なる組合せで相互に頻繁に接続を失い、回復する場合、理論的には、グループがすべてのメンバーに強制マークを付けることができます。その後、グループは存在しなくなり、再度設定する必要があります。 この可能性に対処するために、MySQL 8.0.20 から、Group Replication Group Communication System (GCS) は説明のためにマークされたグループメンバーを追跡し、大多数があるかどうかを判断する際に疑わしいメンバーのグループ内にあるかのように処理します。 これにより、グループに少なくとも 1 つのメンバーが残っていることが保証され、グループは引き続き存在できます。 削除されたメンバーがグループから実際に削除されると、GCS は、メンバーに強制マークを付けたレコードを削除して、メンバーがグループに再度参加できるようにします。

障害状況に対する作業グループメンバーのレスポンスを指定するために構成できるグループレプリケーションシステム変数、および障害が疑われるグループメンバーが実行するアクションの詳細は、セクション18.6.6「障害検出およびネットワークパーティション化へのレスポンス」 を参照してください。