クラスタアーキテクチャ

基本概念

クラスタ

OceanBase クラスタは1つまたは複数のリージョンで構成され、リージョンは1つまたは複数のゾーンで構成され、ゾーンは1つまたは複数のOBServerで構成されます。各OBServerには複数のユニットが存在し、各ユニットには複数のログストリーム（Logstream）のレプリカ（Replica）が存在します。各ログストリームは複数のシャーディット（Tablet）を使用できます。

リージョン

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

ゾーン

OceanBase データベースでは、ゾーンとはデータセンターまたは物理的なエリアを指す論理的概念です。通常、複数のストレージノードを含み、これらのノードは物理的に異なるデータセンター、異なるラック、または異なるサーバーに分散配置されます。1つのゾーンには複数のデータセンター（例：データセンター棟）を含めることができますが、1つのデータセンターは1つのゾーンにのみ属します。

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

データの災害復旧以外にも、OceanBase データベースのゾーンはデータシャーディットのコンテナとしても利用できます。データシャーディングとは、データを複数のシャーディットに分割し、異なるシャーディットを異なるノードに保存する技術であり、システムのスループットとパフォーマンスを向上させることができます。OceanBase データベースでは、異なるゾーンを異なるシャーディットのプライマリゾーンとして設定することで、データの分散ストレージと処理を実現します。

OBServer

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

ユニット

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

パーティション

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

Tablet

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

Logstream

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

データストレージの観点から見ると、ログストリームはTabletコンテナとして抽象化され、Tabletデータの追加や管理をサポートします。また、データ均等化や水平スケーリングを実現するために、Tabletを異なるログストリーム間で転送（Transfer）することが可能です。

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

デプロイメントモード

単一マシン障害時に同一パーティションの多数派レプリカが利用可能であることを保証するため、OceanBaseデータベースは同一パーティションの複数レプリカが同一マシンにスケジュールされないようにします。同一パーティションのレプリカは異なるゾーン/リージョンに分散配置されているため、都市レベルの災害やデータセンター障害が発生しても、データの信頼性とデータベースサービスの可用性の両方を保証し、信頼性と可用性のバランスを実現します。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

テナント内のログストリームが各ゾーン上に持つレプリカの配置とタイプを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を比較し、対応するゾーンのレプリカを作成・削除・変換するかどうかを判断します。

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

• 各ログストリームは同一のOBServerノード上に1つのみのレプリカを持ちます。

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

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

  • locality = "F{1}@z1, R{ALL_SERVER}@z1": z1に1つのフル機能レプリカがあり、同じゾーン内の他のマシンに読み取り専用レプリカを作成することを示します（読み取り専用レプリカは存在しなくても構いません）。

RootServiceは、ユーザーが設定したローカリティに基づき、レプリカの作成・削除・移行・タイプ変換を通じて、ログストリームのレプリカ分布とタイプをユーザーの設定に合わせて調整します。

プライマリゾーン

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

プライマリゾーンはゾーンの集合であり、セミコロン（;）で区切ることで異なる優先順位を、カンマ（,）で区切ることで同じ優先順位を表します。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;