クラスタアーキテクチャ

基本概念

クラスタ

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つだけです。

パーティション

パーティションはユーザーが作成する論理的なオブジェクトであり、テーブルデータを分割・管理する仕組みです。ユーザーは、作成、削除、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データベースの革新的な災害復旧機能により、三地域五データセンター構成では都市レベルの災害を無損失で許容でき、同一リージョン三データセンター構成ではデータセンターレベルの障害を無損失で許容できます。

三地域五データセンター構成

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

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レプリカを持つことができます。Localityで非Paxosレプリカを指定できます。例：

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

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

RootServiceは、ユーザーが設定した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;