概要
ユーザーは、クラスタの各ゾーンにおけるデータセンターとリージョンの配置、およびこれらのゾーン上でのテナントレプリカの配置を柔軟に調整することで、テナントのデプロイメントパターンを変更し、異なるディザスタリカバリレベルを実現できます。
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つをホットスタンバイデータベースとし、別の地域に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つのレプリカを損失し、残りの多数派のレプリカが引き続きサービスを提供し、データ損失をゼロに保証します。自動選挙で選出されたリーダーが最適でない場合、または都市レベルの障害による間欠的な影響を避けるために、リーダーを最適なゾーンに切り替えることができます。能動的なリーダー切り替えの詳細な操作については、データベース層の高可用性を参照してください。