Oracle Globally Distributed DatabaseでのRaftレプリケーションの使用
Oracle Globally Distributed Databaseは、分散データベース内のトランザクション実行とデータ・レプリケーションを統合する機能であるRaftレプリケーションで組込みのフォルト・トレランスを提供します。
Raftレプリケーションにより、データ損失ゼロで高速な自動フェイルオーバーが可能になります。すべてのシャードが同じデータ・センターにある場合は、1秒未満のフェイルオーバーを実現できます。Raftレプリケーションはアクティブ/アクティブで、各シャードはデータのサブセットに対する読取りおよび書込みを処理できます。この機能により、プライマリまたはスタンバイ・シャードのない均一な構成が提供されます。
Raftレプリケーションはアプリケーションに対して統合され、透過的です。Raftレプリケーションは、Oracle Data Guardの構成を必要とせずに、Oracle Globally Distributed Databaseの組込みレプリケーションを提供します。Raftレプリケーションでは、シャード・ホスト障害の場合、またはシャードが分散データベースに対して追加または削除された場合に、レプリケーションが自動的に再構成されます。
Raftレプリケーションが有効な場合、分散データベースには複数のレプリケーション・ユニットが含まれます。レプリケーション・ユニット(RU)は、同じレプリケーション・トポロジを持つ一連のチャンクです。各RUには、異なるシャードに配置された複数のレプリカがあります。
レプリケーション・ユニット
Raftレプリケーションが有効な場合、分散データベースには複数のレプリケーション・ユニットが含まれます。レプリケーション・ユニット(RU)は、同じレプリケーション・トポロジを持つ一連のチャンクです。各RUには、異なるシャードに配置された3つのレプリカがあります。
各シャードには、複数のRUからのレプリカが含まれます。これらのレプリカの一部はリーダーであり、一部はフォロワです。Raftレプリケーションは、シャード間のリーダーとフォロワのバランスのとれた分散を維持しようとします。デフォルトでは、各シャードは2つのRUのリーダーであり、他の4つのRUのフォロワです。これにより、すべてのシャードがアクティブになり、ハードウェア・リソースを最適に使用できるようになります。
Oracle Globally Distributed Databaseでは、次のイメージに示すように、RUはチャンクのセットです。
上の図は、シャード、チャンク・セットおよびチャンクの関係を示しています。シャードには、一連のチャンクが含まれます。チャンクは、特定の表ファミリ内の表パーティションのセットです。チャンクは、再ハード化(シャード間のデータ移動)の単位です。同じレプリケーション・トポロジを持つ一連のチャンクをチャンク・セットと呼びます。
Raftグループ
各レプリケーション・ユニットには1つのチャンク・セットのみが含まれ、リーダーと一連のフォロワがあり、これらのメンバーはRaftグループを形成します。レプリケーション・ユニットのリーダーとそのフォロワには、次に示すように、同じチャンク・セットのレプリカが別のシャードに含まれています。シャードは、一部のレプリケーション・ユニットのリーダーである場合と、その他のレプリケーション・ユニットのフォロワである場合があります。
データの特定のサブセットに対するすべてのDMLが最初にリーダーで実行され、フォロワにレプリケートされます。
上のイメージでは、各シャードのリーダーが、その横に星印がある1つの色のチャンクのセットで示され、他の2つのシャードそれぞれでフォロワ(同じ色)を指しています。
レプリケーション・ファクタ
レプリケーション・ファクタ(RF)は、Raftグループの参加者数を決定します。この数には、リーダーとそのフォロワが含まれます。
RUには、書込みに使用できるレプリカの大部分が必要です。
- RF = 3: 1つのレプリカ障害を許容
- RF = 5: 2つのレプリカ障害を許容
ノート:
Oracle Globally Distributed Databaseでは、レプリケーション・ファクタは現在3つに制限されています。Oracle Globally Distributed Databaseでは、レプリケーション・ファクタは分散データベース全体に対して指定されます。つまり、データベース内のすべてのレプリケーション・ユニットに同じRFがあります。
Raftログ
各RUは、ログを保持し、リーダーからフォロワに変更をレプリケートする一連のRaftログおよびOSプロセスに関連付けられます。これにより、複数のRUを1つのシャード内および複数のシャード間で独立してパラレルに操作できます。また、RUの数を変更して、レプリケーションをスケール・アップおよびスケール・ダウンすることもできます。
DMLによって行われたデータへの変更は、Raftログに記録されます。コミット・レコードは、各ユーザー・トランザクションの最後にも記録されます。RaftログはREDOログとは無関係に保持され、行に対する論理的な変更が含まれます。論理レプリケーションにより、フォロワは受信トランザクションに対してオープンであり、すぐにリーダーになれるため、フェイルオーバー時間が短縮されます。
Raftプロトコルは、フォロワがリーダーによって生成された順序と同じ順序でログ・レコードを受信することを保証します。フォロワの半分がコミット・レコードの受信を確認するとすぐに、ユーザー・トランザクションがリーダーでコミットされ、Raftログに書き込まれます。
トランザクション
ビジー状態のシステムでは、複数のコミットが同時に確認されます。トランザクション・コミット・レコードの同期伝播によって、データ損失はゼロになります。ただし、DML変更レコードのフォロワへの適用は、トランザクションのレイテンシへの影響を最小限に抑えるために非同期で実行されます。
リーダー選出プロセス
Raftプロトコルでは、フォロワが指定の期間、リーダーからデータやハートビートを受信しない場合、新しいリーダー選出プロセスが開始されます。
デフォルトのハートビート間隔は150ミリ秒です。ランダム化された選出タイムアウト(最大150ミリ秒)により、複数のシャードが同時に選出をトリガーするのを防ぐため、選出を分割します。
ノード障害
ノードの障害およびリカバリは、アプリケーションへの影響を最小限に抑えながら、自動化された方法で処理されます。
フェイルオーバー時間は3秒未満で、可用性ゾーン間のネットワーク待機時間は10ミリ秒未満です。これには、障害検出、シャード・フェイルオーバー、リーダーシップの変化、新しいリーダーへのアプリケーションの再接続、以前と同様にビジネス・トランザクションの継続が含まれます。
アプリケーションに対する障害の影響は、JDBCドライバでの再試行を構成することでさらに抽象化でき、エンド・カスタマ・エクスペリエンスは、エラーが発生するのでなく、特定のリクエストに時間がかかるようになります。
次の例は、3つのシャードすべてを正常な状態にした分散データベースを示しています。アプリケーション・リクエストは3つのシャードすべてに到達でき、シャード間でリーダーとフォロワ間のレプリケーションが進行中です。
リーダー・ノード障害
レプリケーション・ユニットのリーダーが使用できなくなると、フォロワはRaftプロトコルを使用して新しいリーダー選出プロセスを開始します。
ノードの大部分(定足数)がまだ健全であるかぎり、Raftプロトコルでは、使用可能なノードから新しいリーダーが選出されるようになります。
フォロワの1つが新しいリーダーになることに成功すると、事前通知がシャードからリーダーシップ変更のクライアント・ドライバに送信されます。クライアント・ドライバは、新しいリーダー・シャードへのリクエストのルーティングを開始します。ルーティング・クライアント(UCPなど)は、ONS通知を使用してシャードとチャンク・マッピングを更新し、トラフィックをリーダーにルーティングするように通知されます。
このフェイルオーバーおよび再接続期間中、JDBCドライバ構成で、再試行間隔および再試行回数設定を使用して待機および再試行するようにアプリケーションを構成できます。これらは、現在のRACインスタンスのフェイルオーバー構成と非常によく似ています。
新しいリーダーに接続すると、アプリケーションは以前と同様に引き続き機能します。
次の図は、最初のシャードが失敗したことと、その最初のシャードでリーダーがかつて存在したレプリケーション・ユニットの新しいリーダーが、2番目のシャードの新しいリーダーに置き換えられたことを示しています。
フェイルバック
障害後に元のリーダーがオンラインに戻ると、まず現在のリーダーを識別し、フォロワとしてクラスタに再参加しようとします。障害が発生したシャードがクラスタに再参加すると、リーダーと同期するために、現在の索引に基づいたログがリーダーに要求されます。
リーダーシップ・リバランスは、API SWITCHOVER RU -REBALANCEをコールすることで実行できます。これは必要に応じてスクリプト化することもできます。
現在のリーダーに十分なRaftログがない場合は、データ・コピーAPI (COPY RU)を使用して、適切なフォロワのいずれかからフォロワを再移入する必要があります。
フォロワ・ノード障害
フォロワ・ノードが使用できなくなった場合、リーダーはRaftログをそのフォロワにレプリケートしようとすると失敗します。
リーダーは、失敗したフォロワが再度参加するか、新しいフォロワが置き換わるまで、失敗したフォロワに無期限に到達しようとします。
必要に応じて、新しいフォロワを作成してクラスタに追加する必要があり、前述のように適切なフォロワからデータを同期する必要があります。
Raftレプリケーション・デプロイの例
次の図は、6シャード、12レプリケーション・ユニットおよびレプリケーション・ファクタが3である単純な分散データベースRaftレプリケーション・デプロイを示しています。
各シャードには2つのリーダーと4つのフォロワがあります。各メンバーにはRU番号のラベルが付けられ、接尾辞はリーダー(-L)かフォロワ(-Fn)かを示します。リーダーは星印も付いて示されます。この構成では、2つのシャードで障害が発生したシャードの負荷を引き継ぐことができます。
このデプロイを構成するには、シャード・カタログの作成ステップでGDSCTL CREATE SHARDCATALOG -repl NATIVEを指定します。レプリケーション・ファクタ(-repfactor)は、GDSCTL CREATE SHARDCATALOGまたはADD SHARDGROUPコマンドで指定できます。チャンクの指定と同様に、GDSCTL CREATE SHARDCATALOGまたはADD SHARDSPACEコマンドでレプリケーション・ユニットの数を指定します。