PolarDB:概要

この機能は、次の要件のいずれかを満たすPolarDB for MySQLクラスターでサポートされています。

• PolarDBクラスターはMySQL 5.6を実行し、リビジョンバージョンは5.6.1.0.35以降です。

• PolarDBクラスターはMySQL 5.7を実行し、リビジョンバージョンは5.7.1.0.24以降です。

• PolarDBクラスターはMySQL 8.0.1を実行し、リビジョンバージョンは8.0.1.1.29以降です。

• PolarDBクラスターはMySQL 8.0.2を実行し、リビジョンバージョンは8.0.2.2.12以降です。

次のコアテクノロジーを使用して、PolarDBのホットレプリカ機能でフェールオーバーを実装します。

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

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

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

  • VDSは、PolarStoreに2つのデータモジュールを作成します。Compare-and-Swap (CAS) ブロックとPolar Cluster Registry (PCR) です。

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

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

  

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

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

  2. 元のプライマリノードが回復すると、ロックの取得に失敗します。 次いで、元のプライマリノードは、ホットレプリカノードに劣化される。

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

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

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

  • バッファプール

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

  • 元に戻す

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

  • やり直し

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

  • Binlog

    バイナリログを有効にすると、準備状態の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リンクを介してホットレプリカに連続的に同期される。 バックエンドデータベースに対してバイナリログが有効になっている場合、各トランザクションに対応するローカルバイナリログキャッシュがホットレプリカノードに同期されます。

  

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

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