MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む

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

18.4.3 分散リカバリ

メンバーがレプリケーショングループに参加したり、レプリケーショングループに再度参加したりする場合は、参加前または退席中にグループメンバーによって適用されたトランザクションをキャッチアップする必要があります。 このプロセスは分散リカバリと呼ばれます。

参加メンバーは、グループからすでに受信したがまだ適用されていないトランザクションについて、その group_replication_applier チャネルのリレーログを確認することから始まります。 結合メンバーが以前にグループに属していた場合は、そのメンバーが残ってから未適用のトランザクションが見つかる可能性があります。その場合は、これらを最初のステップとして適用します。 グループの新規メンバーには適用するものがありません。

その後、参加メンバーはオンラインの既存のメンバーに接続して状態の転送を実行します。 参加メンバーは、既存のメンバー (ドナーと呼ばれる) によって提供されている、参加前または退席中にグループで発生したすべてのトランザクションを転送します。 次に、参加メンバーは、この状態の転送の進行中にグループで行われたトランザクションを適用します。 このプロセスが完了すると、参加メンバーはグループ内の残りのサーバーで捕捉され、グループへの通常の参加を開始します。

グループレプリケーションでは、分散リカバリ中の状態転送に次の方法の組合せを使用します:

グループレプリケーションでは、参加メンバーに対して START GROUP_REPLICATION を発行した後、これらの方法の最適な組合せが状態転送に自動的に選択されます。 これを行うために、グループレプリケーションでは、ドナーとして適切な既存のメンバー、ドナーからの参加メンバーに必要なトランザクションの数、およびグループメンバーのバイナリログファイルに必要なトランザクションが存在しなくなったかどうかがチェックされます。 参加メンバーと適切なドナーの間のトランザクションギャップが大きい場合、または一部の必要なトランザクションがドナーのバイナリログファイルにない場合、Group Replication はリモートクローニング操作で分散リカバリを開始します。 大きなトランザクションギャップがない場合、またはクローンプラグインがインストールされていない場合、Group Replication はドナーのバイナリログからの状態転送に直接進みます。

参加メンバーは、すべてのグループトランザクションで最新の状態である場合、オンラインとして宣言され、通常のメンバーとしてグループに参加でき、分散リカバリが完了します。

ヒント

バイナリログからの状態転送は、分散回復のためのグループレプリケーションベースメカニズムであり、レプリケーショングループ内のドナーおよび参加メンバーがクローニングをサポートするように設定されていない場合は、これが唯一使用可能なオプションです。 バイナリログからの状態転送はクラシック非同期レプリケーションに基づいているため、グループに参加しているサーバーにグループデータがまったくない場合、または非常に古いバックアップイメージから取得されたデータがある場合は、非常に長い時間がかかることがあります。 したがって、この状況では、サーバーをグループに追加する前に、グループ内にすでに存在するサーバーのかなり最近のスナップショットを転送して、グループデータを使用して設定することをお勧めします。 これにより、分散リカバリにかかる時間が最小限に抑えられ、保持および転送が必要なバイナリログファイルが少なくなるため、ドナーサーバーへの影響が軽減されます。