Group Replication 分散回復プロセスがバイナリログから状態転送を実行しているときに、参加メンバーを特定の時点までドナーと同期するために、参加メンバーとドナーは GTID を利用します (セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」 を参照)。 ただし、GTID は、参加メンバーが欠落しているトランザクションを認識する手段のみを提供します。 グループに参加するサーバーがキャッチアップする必要がある特定の時点をマークしたり、証明書情報を伝達したりするのに役立ちません。 これはバイナリログビューマーカーのジョブであり、バイナリログストリーム内のビューの変更をマークし、追加のメタデータ情報も含まれており、結合するメンバーに動作保証関連データが提供されます。
このトピックでは、ビュー変更の役割とビュー変更識別子、およびバイナリログから状態転送を実行する手順について説明します。
view は、現在の構成にアクティブに参加しているメンバーのグループ (特定の時点) に対応します。 グループ内で正しくオンラインで機能しています。
変更の表示は、メンバーの参加や離脱など、グループ構成の変更が発生したときに発生します。 グループメンバーシップが変更されると、独立したビュー変更が同じ論理ポイントインタイムのすべてのメンバーに伝達されます。
ビュー識別子はビューを一意に識別します。 ビューの変更が発生するたびに生成されます。
グループ通信レイヤーでは、ビューの変更とそれに関連付けられたビュー識別子により、メンバー結合の前後に交換されたデータ間の境界がマークされます。 この概念はバイナリログイベントを介して実装されます:「変更ログイベントの表示」。 ビュー識別子は、グループメンバーシップでの変更の前後に送信されたトランザクションを境界設定するために記録されます。
ビュー識別子自体は 2 つの部分から作成されます: ランダムに生成された部分と単調に増加する整数。 ランダムに生成されたパーツは、グループの作成時に生成され、グループに少なくとも 1 つのメンバーが存在する間は変更されません。 整数は、ビューの変更が発生するたびに増分されます。 これら 2 つの異なる部分を使用すると、ビュー識別子で、メンバーの参加または離脱によって発生した増分グループ変更を識別したり、すべてのメンバーがグループ全体の停止でグループを離れる状況を識別したりできます。したがって、グループがどのビューにあったかに関する情報は残りません。 グループが最初から起動されたときに識別子の一部をランダムに生成することで、バイナリログ内のデータマーカーが一意のままになり、今後分散リカバリで問題が発生する可能性があるため、完全グループのシャットダウン後も同じ識別子は再利用されません。
すべてのサーバーはオンラインであり、グループからの受信トランザクションを処理しています。 一部のサーバーは、レプリケートされたトランザクションに関して少し遅れている可能性がありますが、最終的には収束します。 グループは、分散データベースおよびレプリケートされたデータベースとして機能します。
新しいメンバーがグループに参加してビューの変更が実行されるたびに、すべてのオンラインサーバーは実行のためにビュー変更ログイベントをキューに入れます。 これは、ビューが変更される前に、複数のトランザクションをサーバー上でキューに入れて適用できるため、キューに入れられます。そのため、これらのトランザクションは古いビューに属します。 ビュー変更イベントをキューに入れると、その発生時の正しいマーキングが保証されます。
一方、参加メンバーは、ビュー抽象化を介してメンバーシップサービスによって記述されているように、オンラインサーバーのリストから適切なドナーを選択します。 メンバーがビュー 4 に参加し、オンラインメンバーがビュー変更イベントをバイナリログに書き込みます。
グループメンバーと結合メンバーがクローンプラグインを使用して設定されていて (セクション18.4.3.2「分散リカバリのためのクローニング」 を参照)、結合メンバーとグループの間のトランザクションの差がリモートクローニング操作 (group_replication_clone_threshold) に設定されたしきい値を超えた場合、グループレプリケーションはリモートクローニング操作で分散回復を開始します。 必要なトランザクションがどのグループメンバーのバイナリログファイルにも存在しない場合は、リモートクローニング操作も実行されます。 リモートクローニング操作中に、参加メンバーの既存のデータが削除され、ドナーデータのコピーに置き換えられます。 リモートクローニング操作が完了し、参加メンバーが再起動すると、ドナーのバイナリログから状態転送が実行され、リモートクローニング操作の進行中にグループが適用したトランザクションが取得されます。 大きなトランザクションギャップがない場合、またはクローンプラグインがインストールされていない場合、Group Replication はドナーのバイナリログからの状態転送に直接進みます。
ドナーバイナリログからのステート転送の場合、参加メンバーとドナーとステート転送の間の接続が確立されます。 このドナーとの相互作用は、グループアプライヤスレッドに参加しているサーバーが、グループに参加しているサーバーがグループに入ったときにトリガーされたビュー変更に対応するビュー変更ログイベントを処理するまで続きます。 つまり、グループに参加するサーバーは、すでに存在するビューマーカーと一致するビュー識別子を持つマーカーに到達するまで、ドナーからレプリケートします。
ビュー識別子はグループ内のすべてのメンバーに同時に送信されるため、グループに参加しているサーバーはレプリケートを停止するビュー識別子を認識します。 これにより、ビュー識別子によって各グループビューに属するデータが明確にマークされるため、複雑な GTID セット計算が回避されます。
グループに参加するサーバーはドナーからレプリケートしていますが、グループからの受信トランザクションもキャッシュしています。 最終的に、ドナーからのレプリケートを停止し、キャッシュされているものを適用するように切り替えます。
グループに参加しているサーバーが予想されるビュー識別子を持つビュー変更ログイベントを認識すると、ドナーへの接続が終了し、キャッシュされたトランザクションの適用が開始されます。 これはバイナリログのマーカーとして機能し、ビューの変更を区切りますが、ビューの変更ログイベントも別の役割を果たします。 これは、グループに参加しているサーバーがグループに入ったときにすべてのサーバーによって認識される動作保証情報、つまり最後のビューの変更を伝達します。 そうしないと、グループに参加しているサーバーには、後続のトランザクションを認証 (競合の検出) するために必要な情報がありません。
キャッチアップの期間は、ワークロードおよびグループへの受信トランザクションの割合に依存するため、決定的ではありません。 このプロセスは完全にオンラインであり、グループに参加しているサーバーはグループ内の他のサーバーをキャッチアップ中にブロックしません。 したがって、このステージに移動すると、サーバーがグループに参加しているトランザクションの数が遅れるため、ワークロードに応じて増減できます。
グループに参加しているサーバーがキューに入れられていないトランザクションに到達し、格納されているデータが他のメンバーと等しい場合、パブリック状態はオンラインに変わります。
