OceanBaseデータベースのアーキテクチャと実装方法は、データの強整合性、完全性、および高可用性を保証します。
OceanBaseデータベースのアーキテクチャ
図に示すように、データサービス層は一つのOceanBaseデータベースクラスタを表します。このクラスタは3つのゾーンから構成され、各ゾーンは複数の物理マシンで構成されており、各物理マシンはデータノード（OBServerノード）と呼ばれます。OceanBaseデータベースはShared-Nothingの分散アーキテクチャを採用しており、各データノードは対等です。
OceanBaseデータベースに保存されるデータは、一つのゾーン内の複数のデータノードに分散して保存され、他のゾーンには複数のデータレプリカが配置されます。図に示すOceanBaseデータベースクラスタのデータには3つのレプリカがあり、各ゾーンに1つずつ保存されています。これら3つのゾーンが一体となったデータベースクラスタを形成し、ユーザーへのサービスを提供します。
デプロイ方法の違いにより、OceanBaseデータベースはさまざまなレベルの災害復旧能力を実現できます：
サーバー（Server）レベルの無損失ディザスタリカバリ：単一サーバーの障害を許容し、自動で無損失で切り替えます。
データセンター（Zone）レベルの無損失ディザスタリカバリ：単一のデータセンターの障害を許容し、自動で無損失で切り替えます。
リージョン（Region）レベルの無損失ディザスタリカバリ：特定の都市全体の障害を許容し、自動で無損失で切り替えます。
データベースクラスタが一つのデータセンターの複数のサーバーにデプロイされている場合、サーバーレベルのディザスタリカバリが実現されます。クラスタのサーバーが一つの地域内の複数のデータセンターにある場合、データセンターレベルのディザスタリカバリが実現されます。クラスタのサーバーが複数の地域の複数のデータセンターにある場合、リージョンレベルのディザスタリカバリが実現されます。
OceanBaseデータベースのディザスタリカバリ能力は、RPO=0、RTO<8秒の国家標準最高の6級基準に達します。
高可用性
OceanBaseの分散クラスタでは、複数のマシンが同時にデータベースサービスを提供し、その高可用性を実現します。上図に示すように、アプリケーション層はリクエストをプロキシサービス（ODP、別名obproxy）に送信します。プロキシサービスでルーティングされた後、実際のサービスデータを保持するデータベースノード（OBServerノード）に送信され、リクエストの結果は逆の経路でアプリケーション層に返されます。このプロセス全体を通じて、異なるコンポーネントがさまざまな方法で高可用性を実現しています。
データベースノード（OBServerノード）で構成されるクラスタでは、すべてのデータがパーティション単位で格納され、高可用性サービスを提供します。各パーティションには複数のレプリカがあります。一般的に、一つのパーティションの複数のレプリカは複数の異なるゾーンに分散しています。複数のレプリカのうち、変更操作を受け付けるのは必ず一つだけで、これをリーダーレプリカ（Leader）と呼び、他のものをフォロワーレプリカ（Follower）と呼びます。リーダーレプリカとフォロワーレプリカの間では、Multi-Paxosに基づく分散型コンセンサスプロトコルにより、レプリカ間のデータ一貫性が保証されます。リーダーレプリカが配置されているノードに障害が発生した場合、フォロワーノードの一つが新しいリーダーノードとして選出され、サービスを継続します。
選挙サービスは高可用性の基盤です。OceanBaseデータベースの以前のバージョンとは異なり、V4.xバージョンでは、選挙サービスの粒度がパーティションからログストリームに変更され、パーティションはログストリームにマウントされます。ログストリームの複数のレプリカは選挙プロトコルにより一つをリーダーレプリカ（Leader）として選出します。このような選挙は、クラスタの再起動時やリーダーレプリカに障害が発生した場合に行われます。
さらに、V4.xバージョンでは、選挙サービスはNTPやその他の時刻同期サービスに依存せず、ローカル時計および改良されたレンタル機構によって時刻の一貫性を保証します。選挙サービスは優先順位機構により、より優れたレプリカをリーダーレプリカとして選出することを保証します。優先順位機構は、ユーザーが指定したプライマリゾーンやマシンの異常状態などを考慮します。
リーダーレプリカがサービスを開始すると、ユーザーの操作により新たなデータ変更が生じ、すべての変更はログとして生成され、他のフォロワーレプリカ（Follower）に同期されます。OceanBaseデータベースがログ情報を同期するプロトコルはMulti-Paxos分散型コンセンサスプロトコルです。Multi-Paxosプロトコルは、コンセンサスに達する必要があるすべてのログ情報が、レプリカリスト内の過半数のレプリカに正常に永続化された後は、いかなる少数派のレプリカに障害が発生しても情報が失われないことを保証します。Multi-Paxosプロトコルによって同期された複数のレプリカは、少数のノードに障害が発生した場合でも、システムの二つの重要な特性を保証します：データが失われないこと、サービスが停止しないこと。ユーザーが書き込んだデータは少数のノードの障害を許容でき、同時に、ノードに障害が発生した場合、システムは常に自動的に新しいレプリカをリーダーレプリカとして選出し、データベースのサービスを継続します。
OceanBaseデータベースの各テナントにはグローバルタイムスタンプサービス（GTS）も備えており、テナント内で実行されるすべてのトランザクションに対して、トランザクションの読み取りスナップショットバージョンとコミットバージョンを提供し、グローバルなトランザクションの順序を保証します。グローバルタイムスタンプサービスに異常が発生した場合、テナントのトランザクション関連操作はすべて影響を受けます。OceanBaseデータベースは、パーティションレプリカと一致する方式を用いて、グローバルタイムスタンプサービスの信頼性と可用性を保証します。テナント内のグローバルタイムスタンプサービスの実際の位置は、特殊なパーティションによって決定されます。この特殊なパーティションも他のパーティションと同様に複数のレプリカを持ち、選挙サービスによってリーダーレプリカが選出されます。リーダーレプリカが配置されているノードがグローバルタイムスタンプサービスのノードとなります。このノードに障害が発生した場合、特殊なパーティションは別のレプリカをリーダーレプリカとして選出し、作業を継続します。グローバルタイムスタンプサービスも自動的に新しいリーダーレプリカが配置されているノードに移行し、サービスを継続します。
以上がデータベースクラスタノードが高可用性を実現するための主要なコンポーネントです。プロキシサービス（ODP、別名obproxy）もまた、自身のサービスを保証するために高可用性が必要です。ユーザーのリクエストは最初にプロキシサービスに到達し、プロキシサービスが正常でなければユーザーのリクエストも正常に処理できません。プロキシサービスはまた、データベースクラスタノードの障害を処理し、適切なフォールトトレランス処理を行う必要があります。
プロキシサービスはデータベースクラスタとは異なり、永続的な状態を持ちません。その業務はすべてデータベースサービスへのアクセスに依存しているため、プロキシサービスの障害はデータ損失を引き起こしません。プロキシサービスも複数のノードでクラスタサービスを構成しており、ユーザーのリクエストを具体的にどのプロキシサービスノードが実行するかは、ユーザーのF5キー操作やその他のロードバランシングコンポーネントが担当します。同時に、プロキシサービスの特定のノードに障害が発生した場合も、ロードバランシングコンポーネントが自動的に除外し、その後のリクエストが障害ノードに送信されないようにします。
プロキシサービスの動作プロセスは、データベースクラスタの状態をリアルタイムで監視します。一方で、プロキシサービスはクラスタのシステムテーブルをリアルタイムで取得し、システムテーブルから各マシンのヘルス状態とパーティションのリアルタイム位置を把握します。他方で、プロキシサービスはネットワーク接続を通じてデータベースクラスタノードのサービス状態を検出し、異常が検出された場合は該当ノードの障害状態をマークし、適切なサービス切り替えを行います。