PolarDB:ホットレプリカによるフェールオーバー

PolarDB でホットレプリカによるフェールオーバー機能を実装するために、以下のコアテクノロジーが活用されています。

• 新しい高可用性モジュール：VDS

  ホットレプリカによるフェールオーバー機能が有効になると、PolarDB は VDS をアクティブにします。PolarDB の共有ディスクアーキテクチャにより、VDS はクラスタノードの自律管理、障害検出、プライマリノード選択を提供します。 VDS のアーキテクチャに関する詳細：

  • VDS 内の各計算ノードには、独立したスレッドがあります。VDS スレッドは、リーダー、フォロワー、オブザーバーの 3 つのカテゴリに分類されます。PolarDB クラスタでは、リーダースレッドはプライマリノードで実行され、フォロワースレッドはホットレプリカノードで実行され、オブザーバースレッドは読み取り専用ノードで実行されます。PolarDB クラスタには、1 つのリーダースレッド、1 つのフォロワースレッド、複数のオブザーバースレッドを含めることができます。

  • VDS は、PolarStore 上に 2 つのデータモジュールを作成します。比較とスワップ（CAS）ブロックと Polar クラスタレジストリ（PCR）です。

    • CAS ブロックは、PolarStore によって提供される CAS 操作をサポートするアトミックデータブロックです。CAS を使用すると、VDS でリースベースの分散ロックが可能になり、ロックホルダーやリース時間などのメタデータが記録されます。PolarDB クラスタのプライマリノードとホットレプリカノードは、ロック取得とロック更新のセマンティクスを使用して、障害を検出し、プライマリノードを選択します。

    • PCR は、クラスタのトポロジステータスなど、PolarDB ノード管理の情報を格納します。リーダースレッドは PCR にデータを書き込む権限を持ちますが、フォロワーおよびオブザーバースレッドは PCR からデータを読み取る権限のみを持ちます。フォロワースレッドがリーダースレッドに指定されると、元のリーダースレッドはフォロワースレッドになります。最新のリーダースレッドのみが PCR にデータを書き込む権限を持ちます。PCR はトポロジも再構築します。

  

  一般的に、プライマリノードは読み取りおよび書き込みサービスを提供し、対応するリーダースレッドは VDS 内のロックを定期的に更新します。プライマリノードが使用できなくなると、ホットレプリカノードが引き継ぎます。プロセスは次のセクションで説明します。

  1. プライマリノードのリースが期限切れになると、フォロワースレッドがロックされ、リーダースレッドとして選択されます。この時点で、ホットレプリカノードはプライマリノードになります。

  2. 元のプライマリノードが回復すると、ロックを取得できません。その後、元のプライマリノードはホットレプリカノードにダウングレードされます。

  3. プライマリノードの選択プロセスが完了すると、PCR は新しいトポロジ情報をすべてのオブザーバースレッドにブロードキャストします。このようにして、読み取り専用ノードは新しいプライマリノードに自動的に接続し、ログシーケンス番号（LSN）とバイナリログの同期リンクを復元できます。

• グローバルプリフェッチシステム

  通常の読み取り専用ノードと比較して、ホットスタンバイノードは特殊な種類の読み取り専用ノードであり、CPU とメモリリソースのごく一部を予約してスイッチオーバー速度を最適化します。グローバルプリフェッチシステムは、ホットレプリカによるフェールオーバーで最も重要なモジュールです。プライマリノードのメタデータをリアルタイムで同期し、重要なデータをメモリにプリフェッチして、フェールオーバー速度を向上させます。グローバルプリフェッチシステムは、バッファプール、アンドゥ、REDO、バイナリログの 4 つのモジュールで構成されています。

  • バッファプール

    バッファプールモジュールは、プライマリノードのバッファプールで Least Recently Used（LRU）アルゴリズムを実装するために使用される連結リストをリアルタイムで監視し、関連データをホットレプリカノードに送信します。ホットレプリカノードは、頻繁にアクセスされるページを選択し、それらをメモリにプリフェッチして、読み取り専用ノードがプライマリノードとして選択されたときにバッファプールヒット率の大幅な低下によって引き起こされるパフォーマンスの低下を回避します。

  • アンドゥ

    アンドゥモジュールは、トランザクションシステムのデータをプリフェッチします。フェールオーバー中に、PolarDB はアンドゥページから保留中のトランザクションを見つけ、トランザクションをロールバックします。読み取り専用ノードは、大規模な分析クエリリクエストのみを処理し、プライマリノードのコミットされていないトランザクションにはアクセスしません。これにより、アンドゥページの I/O 待機時間が長くなります。ホットレプリカによるフェールオーバー機能は、アンドゥページをプリフェッチし、ランタイム適用を使用して最新バージョンに再生することで、トランザクションシステムの回復時間を短縮します。

  • REDO

    REDO モジュールは、ホットレプリカと読み取り専用ノードの REDO ログをメモリの REDO ハッシュテーブルにリアルタイムでキャッシュします。

  • バイナリログ

    バイナリログが有効になると、準備状態の InnoDB トランザクションは、バイナリログに基づいてトランザクションをコミットするかロールバックするかを決定します。多数のトランザクションが実行されると、すべてのバイナリログを読み取って解析するのに数秒または数分かかる場合があります。ホットレプリカノードは、バックグラウンドスレッドを使用して最新のバイナリログを I/O キャッシュに非同期的にキャッシュし、事前に解析してフェールオーバー速度を向上させます。

  PolarDB は、ホットレプリカノードと一般的なスタンバイノード間の動的変換をサポートしています。実際のシナリオでは、1 つのホットレプリカノードを長期間有効にするか、構成の変更やアップグレード中に短時間だけホットレプリカ機能を有効にすることができます。PolarDB では、異なる仕様のプライマリノードと読み取り専用ノードを構成できます。ただし、ディザスタリカバリのために、少なくとも 1 つの読み取り専用ノードでプライマリノードと同じ仕様を使用する必要があります。このノードをホットレプリカノードとして構成することをお勧めします。

• 永続的な接続とトランザクション状態の保持

  ただし、フェールオーバーまたはホットアップグレードはサービスに影響を与え、一時的な接続、接続障害、既存のトランザクションのロールバックなどの問題を引き起こす可能性があります。これにより、アプリケーション開発の複雑さとリスクが増加します。

  PolarDB は、永続的な接続 機能をサポートしています。永続的な接続は、PolarProxy がアプリケーションと PolarDB の間の接続ブリッジとして機能する方法で実装されます。データベースがプライマリ/セカンダリフェールオーバーを実行すると、PolarProxy はデータベースノードをアプリケーションに接続し、元のシステム変数、ユーザー変数、文字セットエンコーディングなどの情報を含む以前のセッションを復元します。

  永続的な接続機能は、アイドル接続にのみ適用できます。ノードが切り替えられた瞬間に、現在のセッションに実行中のトランザクションがある場合、PolarProxy は PolarDB から元のトランザクションコンテキストを取得できません。新しいプライマリノードは、コミットされていないトランザクションをロールバックし、これらのトランザクションによって保持されている行ロックを解放します。この場合、永続的な接続を維持することはできません。この問題を解決するために、PolarDB はトランザクション状態保持機能を提供します。トランザクション状態保持は、永続的な接続機能と組み合わせて、サービスを中断することなく高可用性を実現するための高速フェールオーバーを可能にします。

  バイナリログに基づく論理レプリケーションとは異なり、物理レプリケーションアーキテクチャにより、PolarDB はプライマリノードと同じトランザクションをホットレプリカノードに再構築できます。

  たとえば、アプリケーションでトランザクションをコミットするプロセスは BEGIN > INSERT > UPDATE > COMMIT であり、トランザクション状態保持機能が有効になっているとします。トランザクションの実行が開始されると、PolarProxy は SQL 文をプライマリノードに転送しながら、最後に実行された SQL 文をキャッシュします。INSERT 文がプライマリノードで実行されると、PolarDB は最新の文のセーブポイントをトランザクション情報の一部として自動的に保存します。セッショントラッカーは、現在のセッションとトランザクション情報を PolarProxy に返します。次に、PolarProxy はデータを内部キャッシュに一時的に保存します。文字セットやユーザー変数などのセッション情報は、接続を維持するために使用されます。trx_id や undo_no などのトランザクション情報は、トランザクション状態の保持に使用されます。さらに、トランザクション情報は、個別の RDMA リンクを介してホットレプリカに継続的に同期されます。バックエンドデータベースでバイナリログが有効になっている場合、各トランザクションに対応するローカルバイナリログキャッシュは、ホットレプリカノードに同期されます。

  

  たとえば、PolarDB で UPDATE 文が実行されているときに、プライマリノードが使用できなくなったとします。PolarProxy は、基盤となるレイヤーからのエラーをアプリケーション接続にすぐに送信するのではなく、リクエストを一定期間保持します。フェールオーバー後、新しいプライマリノードは REDO ログに基づいてすべてのコミットされていないトランザクションを構築し、トランザクションをロールバックせずにコミットされていないトランザクションを非同期的に待機できます。PolarProxy がフェールオーバー成功メッセージを検出すると、それ自体でキャッシュされたセッションとトランザクション情報を使用して、PolarDB の Attach Trx API を呼び出すことによってトランザクションを再構築します。PolarDB は、PolarProxy 情報に基づいてトランザクション情報が有効かどうかを判断します。トランザクション情報が有効な場合、接続にバインドされ、最後の文（UPDATE 文）に対応する undo_no のセーブポイントにロールバックされます。

  トランザクションが再構築されると、PolarProxy は SQL 文キャッシュから新しいプライマリノードに実行に失敗した最新の UPDATE 文を再送信できます。フェールオーバープロセス中に、アプリケーションで接続エラーやトランザクションエラーは報告されません。唯一の違いは、UPDATE 文が通常よりも遅くなる可能性があることです。