概要
ユーザーは、クラスタ内の各ゾーンにおけるデータセンターとリージョンの配置、およびこれらのゾーン上でのテナントレプリカの配置を柔軟に調整することで、テナントのデプロイモードを変更し、さまざまなレベルの災害復旧を実現できます。
OceanBaseデータベースがサポートする災害復旧レベルは以下の通りです。
| デプロイメントモード | 最適なレプリカ数 | ディザスタリカバリシナリオ | ディザスタリカバリ能力 |
|---|---|---|---|
| 単一データセンター | 3レプリカ | 複数のデータセンターを利用できない環境向け。 同一データセンター内の3つのレプリカで1クラスタを構成し、同一レプリカは可能な限り同等のディザスタリカバリ能力を持つマシン群に配置します。例：同一ラック、同一電源など。 |
|
| 同一都市3データセンター | 3レプリカ | 1都市に3つのデータセンターがある環境向け。 同一都市の3つのデータセンターで1クラスタを構成します（各データセンターが1ゾーン）。データセンター間のネットワーク遅延は通常0.5～2msです。 |
|
| 2リージョン3データセンター | 5レプリカ | 1都市に2つのデータセンターしかない環境向け。 メイン都市とバックアップ都市で5レプリカのクラスタを構成します。メイン都市の4つのレプリカは2つのIDCに分散配置され、バックアップ都市に1つのレプリカが配置されます。いずれかのIDCで障害が発生しても、最大で2つのレプリカを失うだけで、残りの3つのレプリカで過半数を維持できます。 |
|
| 3リージョン5データセンター | 5レプリカ | 都市レベルのディザスタリカバリ能力が必要な環境向け。 3つの都市で5レプリカのクラスタを構成します。2つの都市にそれぞれ2つのレプリカ、3つ目の都市に1つのレプリカを配置します。いずれかのデータセンターまたは都市で障害が発生しても、過半数を維持でき、RPO=0を保証します。 |
|
3種類のデプロイモードの概要図は以下の通りです：
同一都市内の3センターデプロイモード
2リージョン3センターデプロイモード
3リージョン5センターデプロイモード
OceanBaseデータベースのデプロイモードは、テナントレベルのLocalityプロパティによって記述されます。レプリカ管理の章では、3種類のデプロイモードにおけるLocalityの例を説明しています。テナントのLocalityプロパティを調整することで、柔軟なデプロイモードを実現し、さまざまなレベルの災害復旧を達成できます。詳細については、Localityの紹介を参照してください。
マルチレプリカ技術による災害復旧アーキテクチャの核心的なロジックは、Paxosプロトコルを用いてトランザクションログの過半数承認を保証することです。障害が発生したノードが過半数未満の場合、選出プロトコルにより自動復旧が保証され、RPO = 0となります。しかし、過半数以上のノードに障害が発生した場合は、人の手が必要となり、単一レプリカ方式でサービスを再開することができます。ただし、少数派に最新データが含まれていない可能性があるため、最後の一部のデータが失われる可能性があります。
注意
単一レプリカによるサービス再開は通常の運用保守操作ではなく、クラスタが回復不能な場合の最終的な緊急手段です。データ損失やデュアルプライマリのリスクがあるため、特に慎重に行う必要があります。OceanBaseサポート担当者の指導のもとで実施してください。本ドキュメントでは、操作の詳細は提供していません。
金融業界では、従来のリレーショナルデータベースも「2リージョン3センター」アーキテクチャで構築されることが一般的です。同一都市内に2つのデータセンターを設置し、1つをプライマリデータベース、もう1つをホットスタンバイとし、遠隔地にはコールドスタンバイを配置します。データベース固有の準同期メカニズムを利用すれば、業務更新を保証しつつ、同時にスタンバイデータベースへのコミットも可能ですが、これは強力な保証メカニズムではありません。プライマリデータベースに障害が発生した場合、スタンバイデータベースには最新の更新が反映されていない可能性があり、またスタンバイデータベースを強制的にプライマリに切り替えるとデータ損失が発生する恐れがあります。これはつまり、従来のリレーショナルデータベースの「2リージョン3センター」アーキテクチャでは、高可用性か強い整合性かのどちらか一方を選択せざるを得ず、「CAP理論」を破ることはできないということです。しかし、OceanBaseデータベースのPaxosプロトコルに基づくマルチレプリカ災害復旧技術は、同一都市内および異なるリージョン間での無損失災害復旧を実現し、RPO = 0、RTO < 8秒を達成しています。
OceanBaseデータベースのマルチレプリカ技術によって実現される災害復旧アーキテクチャでは、アプリケーションは単一のデータソースのみを認識するだけで済み、データベース内部での複製の詳細はアプリケーションに対して完全に透過的です。同時に、スタンドアロンレベル、データセンターレベル、さらには都市レベルの障害に対しても無損失の災害復旧機能を提供し、復旧時間は8秒未満です。
スタンドアロン災害復旧
OceanBaseデータベース内部のハートビートメカニズムは、ノード異常を自動的に処理できます。また、OBProxyもノードの異常状態を検出できるため、アプリケーション層がノードの異常状態を検出する必要がなくなります。ノードの非接続型障害によるピンポン効果がアプリケーションに短時間継続的に影響を与えることを防ぐためには、異常ノードを速やかに隔離する必要があります。異常ノードの隔離に関する詳細な操作については、ノードの隔離を参照してください。ノードを隔離した後に自動的に生成されたリーダーが最適でない場合は、プライマリゾーンを指定のゾーンに手動で切り替えることができます。手動リーダー切り替えの詳細な操作については、データベース層の高可用性を参照してください。
障害ノードのその後の処理は、以下の2つのシナリオに分かれます：
障害OBServerは再起動可能です
障害機器が以前どのようなハートビート状態にあったかに関わらず、OBServerが再起動し、OBServerとRoot Service間のハートビートデータパケットが回復すれば、OBServerは再びサービスを提供できます。OBServerの再起動の詳細な操作については、ノードの再起動を参照してください。
障害OBServerが損傷し、再起動不可能です
OBServerが損傷し、再起動不可能であることが確認された場合は、機器交換プロセスを実行する必要があります。つまり、障害ノードをオフラインにし、新しい機器を再オンラインにします。機器交換の詳細な操作については、ノードの交換を参照してください。
データセンター災害復旧
データセンターレベルの災害復旧では、クラスタのデプロイが複数データセンターの要件を満たしている必要があります。例えば、同一都市内の3センター構成や、2地域にまたがる3センター構成などです。このデプロイモードでは、いずれかのデータセンターで障害が発生し、少数派のレプリカが利用不可になっても、残りの多数派のレプリカは引き続きサービスを提供でき、データ損失をゼロに保証します。データセンターの障害が単一のゾーンにのみ影響を与える場合は、Stop Zoneの方法で障害レプリカを隔離できます。Stop Zoneによる障害ゾーンの隔離に関する詳細な操作については、ゾーンの隔離を参照してください。データセンターの障害が複数のゾーンに影響を与える場合は、リーダーを指定のゾーンに手動で切り替えることで対応できます。手動リーダー切り替えの詳細な操作については、データベース層の高可用性を参照してください。
都市レベルの災害復旧
都市レベルの災害復旧では、クラスタのデプロイが複数都市にまたがる要件を満たしている必要があります。例えば、3地域にまたがる5センター構成などです。このデプロイモードでは、いずれかの都市で障害が発生しても、最大で2つのレプリカを失うだけで、残りの多数派のレプリカは引き続きサービスを提供でき、データ損失をゼロに保証します。自動選出されたリーダーが最適でない場合、または都市レベルの障害による間欠的な影響を避けるために、リーダーを最適なゾーンに手動で切り替えることができます。手動リーダー切り替えの詳細な操作については、データベース層の高可用性を参照してください。