ディザスタリカバリアーキテクチャとディザスタリカバリレベル

概要

ユーザーは、クラスタ内の各ゾーンにおけるデータセンターとリージョンの配置、およびテナントレプリカのこれらのゾーンへの配置を柔軟に調整することで、テナントのデプロイメントパターンを変更し、さまざまな災害復旧レベルを実現できます。

OceanBaseデータベースがサポートする災害復旧レベルは以下のとおりです。

3つのデプロイメントパターンの概要図は以下のとおりです：

• 同一リージョン内の3データセンターデプロイメントパターン

  

• 2リージョン・3データセンターデプロイメントパターン

  

• 3リージョン・5データセンターデプロイメントパターン

  

OceanBaseデータベースのデプロイメントパターンは、テナントレベルのローカリティ属性によって記述されます。「レプリカ管理」の章では、3つのデプロイメントパターンのローカリティ例について説明しています。テナントのローカリティ属性を調整することで、柔軟なデプロイメントパターンを実現し、さまざまな災害復旧レベルを達成できます。詳細については、ローカリティの紹介を参照してください。

マルチレプリカ技術の災害復旧アーキテクチャのコアロジックは、Paxosプロトコルを用いてトランザクションログの過半数承認を保証することです。障害が発生したノードが過半数未満の場合、選挙プロトコルにより自動復旧が保証され、RPO = 0となります。過半数以上のノードに障害が発生した場合は、人為的介入が必要となり、単一レプリカでサービスを再開できます。ただし、少数派には最新データが含まれていない可能性があるため、最後のデータが失われる可能性があります。

金融業界では、従来のリレーショナルデータベースも「2リージョン・3データセンター」アーキテクチャで構築されることが一般的です。同一リージョン内に2つのデータセンターを設置し、1つをプライマリデータベース、もう1つをホットスタンバイとし、異なるリージョンに1つのコールドスタンバイを配置します。データベースのネイティブな準同期的メカニズムを利用すれば、ビジネスの更新がバックアップデータベースにも反映されることが保証されますが、これは強力な保証メカニズムではありません。プライマリデータベースに障害が発生した場合、バックアップデータベースには最新の更新が反映されていない可能性があり、無理やりバックアップデータベースをプライマリに切り替えるとデータ損失が発生する可能性があります。これにより、従来のリレーショナルデータベースの「2リージョン・3データセンター」アーキテクチャでは、高可用性か強整合性かを選択せざるを得ず、「CAP理論」を超えることはできませんでした。しかし、OceanBaseデータベースのPaxosプロトコルに基づくマルチレプリカ災害復旧技術は、同一リージョン内外を問わず、真のロスレス災害復旧を実現し、RPO = 0、RTO < 8秒を達成しています。

OceanBaseデータベースのマルチレプリカ技術によって実現された災害復旧アーキテクチャでは、アプリケーションはデータソースを1つだけ認識すればよく、データベース内部での複製の詳細はアプリケーションに対して完全に透過的です。同時に、単一マシンレベル、データセンターレベル、さらには都市レベルの障害に対するロスレス災害復旧機能を提供し、復旧時間は8秒未満です。

シングルマシンの災害復旧

OceanBaseデータベースの内部ペイントロールメカニズムは、ノードの異常を自動的に処理できます。OBProxyもノードの異常状態を検知できるため、アプリケーション層がノードの異常状態を認識する必要はありません。ノードの非切断型障害によるピンポン効果がアプリケーションに短時間影響を及ぼすのを防ぐためには、異常なノードを速やかに隔離する必要があります。異常ノードの隔離に関する操作については、ノードの隔離を参照してください。ノードを隔離した後に自動的に生成されたリーダーが最適でない場合は、プライマリゾーンを指定ゾーンに移行するために、能動的にプライマリを切り替えることができます。能動的なプライマリ切り替えの詳細な操作については、データベース層の高可用性を参照してください。

障害ノードのその後の処理は、以下の2つのシナリオに分けられます：

• 故障したOBServerは再起動可能です

  故障したマシンが以前どのようなペイントロール状態にあったかに関係なく、OBServerが再起動し、OBServerとRoot Service間のペイントロールデータパケットが回復すると、OBServerは再びサービスを提供できます。OBServerの再起動の詳細な操作については、ノードの再起動を参照してください。

• 故障したOBServerが破損し、再起動できません

  OBServerが破損し、再起動できないことを確認した後は、マシン交換のプロセスを実行する必要があります。つまり、故障したノードをオフラインにし、新しいマシンを再オンラインにします。マシン交換の詳細な操作については、ノードの交換を参照してください。

データセンターの災害復旧

データセンターレベルの災害復旧では、クラスタのデプロイが複数データセンター構成の要件を満たしている必要があります。例えば、同一都市内の3センター構成や2地域3センター構成などです。このデプロイモードでは、いずれかのデータセンターで障害が発生し、少数派のレプリカが利用不能になっても、残りの多数派レプリカが引き続きサービスを提供し、データ損失をゼロに保証します。データセンターの障害が単一のゾーンのみに影響した場合は、Stop Zoneの方法で障害レプリカを隔離できます。Stop Zoneによる障害ゾーンの隔離に関する操作については、Zoneの隔離を参照してください。データセンターの障害が複数のゾーンに影響した場合は、能動的にプライマリを切り替える方法でリーダーを指定ゾーンに切り替えることができます。能動的なプライマリ切り替えの詳細な操作については、データベース層の高可用性を参照してください。

都市レベルの災害復旧

都市レベルの災害復旧では、クラスタのデプロイが複数都市構成の要件を満たしている必要があります。例えば、3地域5センター構成などです。このデプロイモードでは、いずれかの都市で障害が発生しても、最大で2つのレプリカを損失し、残りの多数派レプリカが引き続きサービスを提供し、データ損失をゼロに保証します。自動選挙で選出されたリーダーが最適でない場合、または都市レベルの障害による間欠的な影響を避けるために、プライマリを切り替える方法でリーダーを最適なゾーンに切り替えることができます。能動的なプライマリ切り替えの詳細な操作については、データベース層の高可用性を参照してください。