PolarDB:2つのリージョンにまたがる3つのデータセンター

加重選挙メカニズム

PolarDB-Xは、2つのリージョンアーキテクチャにわたる3つのデータセンターに重み付き選択メカニズムを導入します。

• 楽観的加重選挙メカニズム: Paxosプロトコルベースの選挙では、選挙を開始する可能性が高いノードがリーダーになる傾向があります。 リーダー選出プロセスを最適化するために、楽観的重み付け選出機構は、リーダーとして選出されるノードの尤度に影響を与えるようにノードに重みを割り当てる。 この機構は、ノード上でリーダー選択を開始するために計算された遅延を課し、これは、ノードの割り当てられた重みに反比例する。 その結果、より高い重みを有するノードは、最初にリーダー選択を開始することができる。

• 必須の重み付き選択メカニズム: 新しいリーダーノードが、すべてのノードの中で最も高い重みを持つノードではないと判断した場合 (すべてのノードの重みが同じであるシナリオには適用できません) 、すぐには書き込み操作を許可しません。 代わりに、退位段階として知られる選挙タイムアウト期間に入ります。 退位段階の間、新しいリーダーノードは、周期的に (例えば、1〜2秒毎に) ハートビート信号を他のノードに送信する。 放棄フェーズが終了する前に、新しいリーダーノードが、より高い重みを有する別のノードから応答を受信する場合、新しいリーダーノードは、最も高い重みを有するノードに向けてリーダーシップ転送をトリガする。

PolarDB-Xの2つのリージョンアーキテクチャにわたる3つのデータセンターのレプリカの選択重み:

プライマリデータセンター1のリーダレプリカが失敗すると、リーダー選択プロセスがトリガーされます。 7の選択重みを有する同じデータセンター内のフォロワーレプリカは、新しいリーダーとしての選択のために優先される。 この構成は、同じデータセンタ内のノードの選択を支持するポリシーと一致する。

レプリカ数量の動的調整

5つのレプリカ多数コンセンサスレプリケーショングループを使用する2つのリージョンにわたる3つのデータセンターアーキテクチャでは、データの一貫性を実現するには、少なくとも3つのレプリカからの同期応答が必要です。 一次データセンター内の4つのレプリカは、地理的に近接しているためにネットワークの待ち時間が短いため、しばしば約1ミリ秒以内に、迅速に多数決同期に達することができる。 ただし、プライマリデータセンターで障害が発生し、レプリカが3つしか残っていない場合、システムはセカンダリデータセンターのレプリカが応答するのを待つ必要があります。 その結果、多数決ベースの同期のネットワーク待ち時間は30ミリ秒増加します。 金融業界など、2つの領域にまたがる3つのデータセンタのアーキテクチャが一般的に使用される業界では、一次センタと二次データセンタとの間のネットワーク待ち時間は約30ミリ秒である。

一般的なレプリカ数量調整シナリオ:

• 5つのレプリカが3つのレプリカに減少しました。 downgrad_followerコマンドを実行して、2つのレプリカのロールをフォロワーロールから学習者ロールに動的に変更します。

• 3つのレプリカが5つのレプリカに増えました。 upgrade_learnerコマンドを実行して、2つのレプリカのロールをlearnerロールからfollowerロールにアップグレードします。 2つのレプリカのロールをアップグレードする前に、レプリカの非同期レプリケーションログが最新であることを確認してください。

• 1つのレプリカが3つのレプリカに増えました。 add_followerコマンドを実行して、新しいレプリカをシステムに動的に追加します。 新しいレプリカは最初に学習者の役割を引き受けます。 新しいレプリカのログが現在のデータで更新されると、レプリカは自動的にフォロワーロールにアップグレードされます。

単一レプリカの強制開始

プライマリデータセンターが2つのリージョンアーキテクチャにまたがる3つのデータセンターで障害を起こした場合、セカンダリデータセンターの残りのレプリカは、多数合意プロトコルの要件を満たしていないため、データサービスを提供できません。

PolarDB-Xは、「単一レプリカの強制開始」と呼ばれる機能を提供することで、この問題に対処します。force_single_modeコマンドを実行すると、単一のレプリカを使用してシステムが動作するモードに強制的に移行できます。 プライマリデータセンターが障害から回復し、正常な状態に復元すると、PolarDB-Xは動的レプリカ品質調整機能を使用して、分散システムを徐々に再構築します。 レプリカの数を1から3に増やし、次に5に増やします。 その結果、完全なデータサービスが復元され、システムの冗長性が保証される。

リモートセカンダリインスタンス

金融業界には、地理的発見メトリックのための特定の要件があります。回復時間目標 (RTO) とRPOです。 次の表に、要件を示します。

ジオディザスタリカバリのRTO要件を満たすために、PolarDB-Xは、Paxos多数決コンセンサスプロトコルに基づく5つのレプリカを使用し、プライマリおよびセカンダリインスタンスを組み込んだ2つのリージョンアーキテクチャにまたがる3つのデータセンターを使用します。 一次データセンターに完全な障害が発生した場合、ビジネスオペレーションは、復旧のためにリモートの二次インスタンスに迅速にリダイレクトされ得る。

プライマリインスタンスとセカンダリインスタンスを組み込んだ2つのリージョンアーキテクチャにわたる3つのデータセンターの主な設計ポイント:

• PolarDB-Xのプライマリインスタンスは、少なくとも3つのレプリカからの同期応答を必要とするクロスリージョンPaxosレプリケーションプロトコルを使用します。 デフォルトでは、プライマリデータセンターの4つのレプリカは、ネットワーク遅延が少ないため、同期された応答の大部分をすばやく完了できます。 ほとんどの場合、プライマリインスタンスのリモートレプリカは非同期で応答します。 その結果、プライマリインスタンスの同期プロセスは、リモートレプリカのネットワーク遅延の影響を受けません。

• ほとんどの場合、PolarDB-Xのセカンダリインスタンスはリモートの場所にデプロイされます。 PolarDB-XはChange Data Capture (CDC) ログノードを使用して、異なるリージョンにわたるプライマリインスタンスとセカンダリインスタンス間の準リアルタイムレプリケーションを可能にします。 データ複製待ち時間は、リモートセカンダリインスタンスで発生する可能性があります。 トランザクションの不整合を防ぐために、分散トランザクションシナリオでアトミック複製を確保する必要があります。

• 2つのリージョンアーキテクチャにまたがる3つのデータセンターが関与するシナリオでは、異なるPaxosグループに属するリモートレプリカへのレプリケーションの進行状況は、分散トランザクションでは異なる場合があります。 この場合、プライマリインスタンスからセカンダリインスタンスにデータをレプリケートするには、リモートリージョンにCDCログノードをデプロイして、分散トランザクションを並べ替えて再編成し、インスタンス間でトランザクションをアトミックにレプリケーションする必要があります。 この方法では、プライマリインスタンスからセカンダリインスタンスへのデータレプリケーション中にトランザクションが部分的にコミットされないようにします。 アトミックトランザクションレプリケーションを使用することで、業務がリモートセカンダリインスタンスに移行される際に、定期的なディザスタリカバリのドリルや実際の障害シナリオでトランザクションデータの整合性を確保できます。

PolarDB-Xインスタンスの作成

PolarDB-Xインスタンスを購入すると、トポロジパラメーターを2つのリージョンにまたがる3つのデータセンターに設定できます。

PolarDB-Xインスタンスのトポロジの表示

インスタンスの [基本情報] ページに移動します。 [トポロジ情報] セクションでリソースのゾーン情報を表示します。

フェールオーバーの実行

1. PolarDB for Xscaleコンソールにログインします。

2. 上部のナビゲーションバーで、ターゲットインスタンスが配置されているリージョンを選択します。

3. インスタンスページで、PolarDB-X 2.0タブをクリックします。

4. 対象インスタンスを見つけ、そのIDをクリックします。

5. インスタンスの [基本情報] ページに移動します。 [トポロジ情報] セクションの右上隅にある [プライマリゾーンの指定] をクリックします。

6. [プライマリゾーンの指定] ダイアログボックスで、[データセンター] 、[プライマリゾーン] 、および [モードの切り替え] パラメーターを設定します。

7. [OK] をクリックします。