クラスタアーキテクチャ

基本概念

クラスタ

OceanBaseクラスタは1つまたは複数のRegionで構成され、Regionは1つまたは複数のZoneで構成され、Zoneは1つまたは複数のOBServerで構成されます。各OBServerには複数のUnitがあり、各Unitには複数のログストリーム(Logstream)のレプリカ(Replica)があり、各Logstreamは複数のシャード(Tablet)を使用できます。

Region

Regionは物理的に1つの都市または地域に対応します。OceanBaseクラスタが複数のRegionで構成されている場合、データベースのデータおよびサービス機能は地域レベルの災害復旧機能を備えます。一方、クラスタに1つのRegionしかない場合、都市全体の障害が発生すると、データベースのデータおよびサービス機能に影響が出ます。

Zone

OceanBaseデータベースにおいて、Zoneとは1つのデータセンターまたは物理的なエリアを指し、これは論理的な概念です。通常、複数のストレージノードを含み、これらのノードは物理的に異なる機械室、異なるラック、または異なるサーバーに配置されることがあります。1つのZoneには複数のデータセンター（例えば機械室）を含むことができますが、1つのデータセンターは1つのZoneにしか属さないことができません。

OceanBaseデータベースでは、Zoneは通常、データセンター間のデータ災害復旧を実現するために使用されます。OceanBaseは一定のルールに従ってデータを異なるZoneに分散することで、データの冗長バックアップを実現します。1つのZoneで障害が発生した場合、システムは自動的に予備Zoneのデータに切り替えることで、データの可用性を保証します。

データ災害復旧に加えて、OceanBaseデータベースのZoneはデータシャーディングのコンテナとしても使用できます。データシャーディングとは、データを複数のシャードに分割し、異なるシャードを異なるノードに格納する技術であり、システムのスループットとパフォーマンスを向上させることができます。OceanBaseデータベースでは、異なるZoneを異なるシャードのPrimary Zoneとして使用することで、分散型のデータストレージと処理を実現できます。

OBServer

observerプロセスを実行する物理マシンです。1台の物理マシンには1つまたは複数のOBServerをデプロイできます（通常、1台の物理マシンには1つのOBServerのみをデプロイします）。OceanBaseデータベース内部では、ServerはそのIPアドレスとサービスポートによって一意に識別されます。

Unit

テナントがOBServerノード上に持つコンテナであり、OBServer上で利用可能なリソース（CPU、MEMORYなど）を記述します。1つのテナントは1つのOBServer上に同時に1つのUnitしか存在できません。

Partition

パーティション(Partition)はユーザーが作成する論理オブジェクトであり、テーブルデータを分割および管理するための仕組みです。ユーザーは、作成、削除、Truncate、分割、メジャーコンパクション、交換など、さまざまなパーティション管理操作を実行できます。

Tablet

OceanBaseデータベースV4.0.0バージョンでは、実際のデータストレージオブジェクトを表すために、シャード(Tablet)という概念が導入されました。Tabletはデータを格納する機能を備え、マシン間での移行(Transfer)をサポートしており、データ均等化の最小単位です。Tabletはパーティションと1対1で対応しており、単一パーティションテーブルでは1つのTabletが作成され、複数パーティションテーブルでは各パーティションごとに1つのTabletが作成されます。インデックステーブルの各パーティションにもそれぞれ1つのTabletが対応し、これにはローカルインデックステーブルとグローバルインデックステーブルが含まれます。特に、ローカルインデックステーブルのTabletは主テーブルのTabletと強制的に結合され、同一マシン上に保存されることを保証します。

Logstream

ログストリーム(Logstream, LS)は、OceanBaseデータベースが自動的に作成および管理するエンティティであり、複数のTabletと順序付きRedoログストリームを含む一連のデータを表します。Paxosプロトコルを通じて複数レプリカ間のログ同期を実現し、レプリカ間のデータ整合性を保証し、高可用性を実現しています。ログストリームのレプリカは、マシン管理およびシステム災害復旧を目的として、異なるマシン間での移行(Migration)や複製(Replication)をサポートしています。

データストレージの観点から見ると、ログストリームはTabletコンテナとして抽象化でき、Tabletデータの追加および管理をサポートし、Tabletを異なるログストリーム間で転送(Transfer)することで、データの均等化と水平スケーリングを実現できます。

トランザクションの観点から見ると、ログストリームはトランザクションのコミット単位です。トランザクションの変更が単一のログストリーム内で完了する場合、1フェーズの原子コミットを採用できます。トランザクションの変更が複数のログストリームにまたがる場合、OceanBaseデータベースが最適化した2フェーズのコミットプロトコルを使用して原子コミットを完了し、ログストリームは分散トランザクションの参加者となります。

デプロイモード

単一マシンの障害時に同一パーティションの多数派レプリカが利用可能であることを保証するため、OceanBaseデータベースは同一パーティションの複数のレプリカを同一マシン上にスケジュールしないようにします。同一パーティションのレプリカが異なるZone/Regionに分散しているため、都市レベルの災害やデータセンター障害発生時にもデータの信頼性とデータベースサービスの可用性を両立させ、信頼性と可用性のバランスを実現します。OceanBaseデータベースの革新的な災害復旧機能として、3リージョン5データセンター構成により都市レベルの災害に対して損失なく耐えられるほか、同一リージョン3データセンター構成によりデータセンターレベルの障害に対しても損失なく耐えられます。

3リージョン5データセンター構成

同一リージョン3データセンター構成

OceanBaseデータベースの損失なき災害復旧機能は、クラスタの運用保守作業を容易にすることも可能です。データセンターやサーバーの交換・修理が必要な場合、該当するデータセンターまたはサーバーを直接オフラインにして交換・修理を行い、新しいデータセンターまたはサーバーを追加するだけで済みます。OceanBaseデータベースは自動的にログストリームレプリカの複製と均衡を行うため、このプロセス全体でデータベースサービスの使用に影響はありません。

RootService

OceanBaseデータベースクラスタには、特定のOBServer上で実行される総合管理サービス（RootService）が存在します。RootServiceが配置されているマシンに障害が発生した場合、残りのOBServerが新しいRootServiceを選出します。RootServiceは主にリソース管理、災害復旧、ロードバランシング、スキーマ管理などの機能を提供します。その中で：

• リソース管理

  Region/Zone/OBServer/Resource Pool/Unitなどのメタ情報の管理を含み、例えば：OBServerのオンライン/オフライン、Tenantリソース仕様の変更などが可能です。

• ロードバランシング

  Unitを複数のマシン間でどのように分散させるかを決定します。

• 災害復旧

  自動複製や移行などの手段を通じて、ログストリームの分布とタイプがユーザー指定のLocalityと最終的に一致するように保証します。

• スキーマ管理

  DDLリクエストを処理し、新しいスキーマを生成する役割を担います。

Locality

テナント内のログストリームが各Zone上に持つレプリカの分布とタイプをLocalityと呼びます。テナントを作成する際にLocalityを指定することで、テナント内のログストリームの初期レプリカのタイプと分布を決定でき、その後、テナントのLocalityを変更することで修正が可能です。

以下の文は、mysql_tenantテナントを作成し、そのテナント内のログストリームがz1、z2、z3上で全機能型レプリカであることを示しています。

obclient> CREATE TENANT mysql_tenant RESOURCE_POOL_LIST =('resource_pool_1'), primary_zone = "z1;z2;z3", locality ="F@z1, F@z2, F@z3" setob_tcp_invited_nodes='%';

以下の文は、mysql_tenantのLocalityを変更し、そのテナント内のログストリームがz1、z2では全機能型レプリカ、z3ではログ型レプリカとなるようにします。OceanBaseデータベースは、テナントの新旧Localityを比較した上で、対応するZoneのレプリカを作成/削除/変換するかどうかを決定します。

ALTER TENANT mysql_tenant set locality = "F@z1, F@z2, L@z3";

• 同一OBServerノード内には、ログストリームごとに1つのレプリカしか存在しません。

• 1つのログストリームについて、1つのZone内に最大1つのPaxosレプリカが存在し、複数の非Paxosレプリカを持つことができます。Locality内で非Paxosレプリカを指定できます。例：

  • locality = "F{1}@z1, R{1}@z1"：z1に1つの全機能型レプリカと1つの読み取り専用型レプリカがあることを示します。

  • locality = "F{1}@z1, R{ALL_SERVER}@z1": z1に1つの全機能型レプリカがあり、同一Zone内の他のマシン上に読み取り専用型レプリカを作成することを示します（読み取り専用型レプリカは不要でも構いません）。

RootServiceは、ユーザー設定のLocalityに基づき、レプリカの作成/削除/移行/タイプ変換を行うことで、ログストリームのレプリカ分布とタイプがユーザー設定のLocalityを満たすようにします。

プライマリゾーン

ユーザーはテナントレベルの設定により、テナント内のログストリームのリーダーを指定されたゾーンに配置することができます。この場合、リーダーが存在するゾーンをプライマリゾーンと呼びます。

プライマリゾーンはゾーンの集合であり、セミコロン（;）で区切ることで異なる優先順位を示し、カンマ（,）で区切ることで同じ優先順位を示します。RootServiceはユーザーが設定したプライマリゾーンに基づき、優先順位の高い順にログストリームのリーダーを可能な限り高優先順位のゾーンにスケジュールし、同一優先順位のゾーン間ではリーダーを異なるマシンに分散します。プライマリゾーンを設定しない場合、テナントのすべてのゾーンが同一優先順位と見なされ、RootServiceはテナントのログストリームのリーダーをすべてのゾーンのマシンに分散します。

ユーザーはテナントレベルの設定により、テナントのプライマリゾーンを設定または変更できます。

例：

• テナント作成時にプライマリゾーンを設定し、優先順位を z1 = z2 > z3 とします。

  obclient> CREATE TENANT mysql_tenant RESOURCE_POOL_LIST =('resource_pool_1'), primary_zone = "z1,z2;z3", locality ="F@z1, F@z2, F@z3" setob_tcp_invited_nodes='%';
  

• テナントのプライマリゾーンを変更し、優先順位を z1 > z2 > z3 とします。

  obclient> ALTER TENANT mysql_tenant set primary_zone ="z1;z2;z3";
  

• テナントのプライマリゾーンを変更し、優先順位を z1 = z2 = z3 とします。

  obclient> ALTER TENANT mysql_tenant set primary_zone =RANDOM;