レプリカの紹介

レプリカの概念

レプリカはOceanBaseデータベースのストレージエンジンにおける概念であり、同一のデータを異なるノードにコピーしたものを指します。ここでのデータとはユーザーレベルの概念です。

OceanBaseデータベースの観点から言えば、データパーティションを指します。各データパーティションはテナントのローカリティ属性に基づいて複数のレプリカが冗長化されており、優れた水平スケーラビリティとより高度な災害復旧能力を提供します。

データパーティションとは、一定のテーブル作成ルールに従って、テーブルまたはインデックスを複数のより小さく管理しやすい部分に分割することです。各データパーティションは独立したオブジェクトであり、独自の名前とオプションのストレージ特性を持ちます。

レプリカの役割

レプリカはOceanBaseデータベースの可用性とフォールトトレランスを向上させます。レプリカは異なる地理的場所に配置され、ネットワーク障害やデータセンター障害に対応します。

OceanBaseデータベースは、パーティションレプリケーションやログ同期などの方法でデータを複数のレプリカに複製し、データ損失を防ぎます。これにより、少数派のレプリカに障害が発生した場合でも、無損失のデータベースサービスを提供し続けることが保証されます。

レプリカの種類

OceanBaseデータベースのストレージエンジンは階層型LSM-Tree構造を採用しており、データは基線データと増分データの2つに分かれています。

基線データはディスクに永続化されるデータであり、一度生成されると変更されることはありません。これをSSTableと呼びます。

増分データはメモリ上に存在し、ユーザーによる書き込みはまず増分データに書き込まれます。これをMemTableと呼び、RedoLogによってトランザクション性（CommitLog、略称CLogとも呼ばれる）が保証されます。

これらのデータは複数のレプリカに冗長化されており（例えば、同一リージョンの3センター構成では3つ、3リージョンの5センター構成では5つ）、複数のノードに分散されています。トランザクションのコミット時には、Paxosプロトコルを利用して複数のノード間でRedoLogを同期し、多数派コミットを達成することで、レプリカ間のデータ一貫性を維持します。

OceanBaseデータベースの現行バージョンでサポートされているレプリカの種類は以下のとおりです：

• フル機能レプリカ

  フル機能レプリカは通常レプリカとも呼ばれ、FULLという名前で、略称はFです。RedoLog、MemTable、SSTableなど、すべての完全なデータと機能を備えています。

  フル機能レプリカにはロールの概念があり、データパーティションにもロールがあります。それぞれLeaderとFollowerです。Leaderは主に外部への書き込みサービスと強整合性読み取りサービスを提供し、弱整合性読み取りサービスも提供できます。Followerは外部へ弱整合性読み取りサービスを提供し、Leaderに障害が発生した場合には迅速に切り替わって外部へサービスを提供することもできます。

  フル機能レプリカは必須レプリカであり、テナントのフル機能レプリカの数は1つ以上でなければなりません。フル機能レプリカの詳細については、フル機能レプリカを参照してください。

• 読み取り専用レプリカ

  読み取り専用レプリカの名前は READONLY で、略称は R です。フル機能レプリカとは異なり、読み取り専用レプリカは読み取り機能のみを提供し、書き込み機能は提供しません。ログストリームのフォロワーレプリカとしてのみ機能し、選挙やログの投票には参加せず、ログストリームのリーダーレプリカに選出されることもありません。

  読み取り専用レプリカはオプションのレプリカであり、ユーザーはビジネスの実際のニーズに応じてデプロイするかどうかを選択できます。読み取り専用レプリカの詳細については、読み取り専用レプリカを参照してください。

• カラムストアレプリカ

  カラムストアレプリカの名前は COLUMNSTORE で、略称は C です。カラムストアレプリカとは、同一のログストリーム上でユーザーテーブルのベースラインデータがすべてカラムストアモードで保存されるレプリカのことです。ここでいうユーザーテーブルにはレプリケーションテーブルが含まれますが、インデックステーブル、内部テーブル、システムテーブルなどは含まれません。例えば、ユーザーが F レプリカ上に行ストアテーブルを作成した場合、そのテーブルは C レプリカが存在するマシン上でカラムストア形式で保存されます。読み取り専用レプリカ R と同様に、カラムストアレプリカも選挙やログ投票には参加せず、完全な SSTable、clog、MemTable を保持します。

  カラムストアレプリカはオプションのレプリカであり、通常は分析処理 (AP) シナリオで使用されます。ユーザーはビジネスの実際のニーズに応じてデプロイするかどうかを選択できます。カラムストアレプリカの詳細については、カラムストアレプリカを参照してください。

  AP シナリオにおけるカラムストアレプリカの詳細なデプロイ方法については、OceanBase AP デプロイ概要を参照してください。

ログストリームの紹介

ログストリームの概念

ログストリームは、OceanBase データベースが自動的に作成および管理するエンティティであり、複数のデータパーティション、それらに対するトランザクション操作のログ、およびトランザクション管理構造を含む一連のデータの集合を表します。RedoLog は Paxos プロトコルに基づいて実装されたログモジュールであり、複数レプリカ間のログ同期を実現し、レプリカ間のデータ一貫性を保証し、データの高可用性を実現します。TxCtxMgr はトランザクション管理構造であり、ログストリーム内のすべてのデータパーティションの変更はログストリーム内部で原子的にコミットされます。トランザクションが複数のログストリームにまたがる場合は、OceanBase が最適化した 2 フェーズコミットプロトコルを使用してトランザクションの原子的なコミットを完了します。ログストリームは分散トランザクションの参加者です。

ログストリームは OceanBase データベース V4.0 で新たに導入された概念です。OceanBase データベース V4.0 は、OceanBase データベース V3.x と比較して、トランザクションコミットの基本単位を変更したことが最大の変更点であり、これによりリソース、パフォーマンス、機能の 3 つの側面で大きな価値をもたらしました。

• OceanBase データベース V3.x では、OceanBase データベースはパーティション単位でトランザクションをコミットします。パーティション内の変更は、そのパーティション内の WAL が変更の原子性を保証します。各パーティションは 2 フェーズコミットの参加者となり、トランザクションコミットの基本単位はパーティションです。

• OceanBase データベース V4.x では、OceanBase データベースはログストリーム単位でトランザクションをコミットします。ログストリーム内の変更は、そのログストリーム内の WAL が変更の原子性を保証します。各ログストリームは 2 フェーズコミットの参加者となり、トランザクションコミットの基本単位はログストリームです。

ブロードキャストログストリーム

V4.2.0 から、OceanBase データベースはブロードキャストログストリームという新しい概念を導入しました。あるテナントの最初のレプリケーションテーブルが作成されると同時に、システムは特別なログストリームを作成します。これをブロードキャストログストリームと呼びます。その後、新しく作成されるレプリケーションテーブルはすべてこのブロードキャストログストリームに作成されます。ブロードキャストログストリームと通常のログストリームの違いは、ブロードキャストログストリームはテナント内の各 OBServer ノードに自動的にレプリカをデプロイし、理想的な状況下では任意の OBServer ノードでレプリケーションテーブルの強整合性読み取りを提供できるようにする点です。

一般的に、整合性プロトコルの投票に参加するレプリカが多すぎると、多数派を形成するのに必要な時間が長くなります。テナント内の OBServer ノードが多い場合、すべての OBServer 上のレプリカが投票に参加することは自然と不可能です。そのため、ブロードキャストログストリームでは、投票に参加する必要のない OBServer には R レプリカ（READONLY レプリカ、読み取り専用レプリカ）をデプロイし、投票に参加する必要のある OBServer ノードには通常の F レプリカ（FULL レプリカ、フル機能レプリカ）をデプロイします。

ブロードキャストログストリームと通常のログストリームのレプリカに関する違いは以下のとおりです：

• 通常のログストリームでは、各ゾーンには 1 つのレプリカしか存在できず、そのレプリカタイプは Locality で指定されたレプリカタイプと一致している必要があります。

• ブロードキャストログストリームでは、各ゾーン内で、Locality で記述されているそのゾーンのレプリカタイプに加えて、そのゾーン内でそのテナントの Unit リソースを持つ他のマシンにも、それぞれ 1 つの読み取り専用レプリカが配置されます。Locality でレプリカタイプが指定されていないゾーンには、レプリカは配置されません。

ブロードキャストログストリームの使用制限は以下のとおりです：

• sys テナントとすべての Meta テナントにはブロードキャストログストリームがなく、レプリケーションテーブルの作成はサポートされません。

• 各ユーザーテナントは最大で 1 つのブロードキャストログストリームしか持てません。

• ブロードキャストログストリームと通常のログストリーム間の属性変換はサポートされていません。

• ブロードキャストログストリームの手動削除はサポートされていません。現在、ブロードキャストログストリームはテナントの削除と共に削除される仕組みとなっています。

ログストリームの基本情報の確認

DBA_OB_LS ビューを使用すると、テナント内のすべてのログストリームの基本情報（ステータス、ログ進捗状況など）を確認できます。例：

• 通常ログストリームの確認

  システムテナントとユーザーテナントは、それぞれ自身のテナントに対応するログストリームの基本情報を確認できます。以下の例はシステムテナントで実行したもので、システムテナントが持つ唯一のログストリームである1号ログストリームが表示されています。

  obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_LS limit 1;
  

  結果は次のとおりです。

  +-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+-----------+-----------+
  | LS_ID | STATUS | PRIMARY_ZONE                           | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN | DROP_SCN | SYNC_SCN | READABLE_SCN | FLAG      | UNIT_LIST |
  +-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+-----------+-----------+
  |     1 | NORMAL | sa128_obv4_2;sa128_obv4_1,sa128_obv4_3 |             0 |           0 |       NULL |     NULL |     NULL |         NULL |           |           |
  +-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+-----------+-----------+
  1 row in set
  

• ブロードキャストログストリームの確認

  ブロードキャストログストリームの情報はユーザーテナントのみが確認でき、システムテナントにはブロードキャストログストリームは存在しません。以下の例はユーザーテナントで実行したもので、ユーザーテナントのブロードキャストログストリーム情報が表示されています。レプリケーションテーブルはこのログストリーム上に作成されます。

  obclient(root@mysql001)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_LS WHERE flag LIKE "%DUPLICATE%";
  

  結果は次のとおりです。

  +-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
  | LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN          | DROP_SCN | SYNC_SCN            | READABLE_SCN        | FLAG      | UNIT_LIST |
  +-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
  |  1003 | NORMAL | z1;z2        |             0 |           0 | 1683267390195713284 |     NULL | 1683337744205408139 | 1683337744205408139 | DUPLICATE |           |
  +-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
  1 row in set
  

ログストリームのロケーション情報とロール情報の確認

ログストリームにはロケーション情報があり、どのノードに分散しているかが記録されています。oceanbase.DBA_OB_LS_LOCATIONS ビューの MEMBER_LIST フィールドと LEARNER_LIST フィールドを使用して、フル機能レプリカと読み取り専用レプリカの分散状況をそれぞれ確認できます。データパーティションは独立したロケーション情報を持たなくなり、所属するログストリームのロケーションによって決定されます。ログストリームは異なるノード間で移行や複製が可能であり、パフォーマンスの均等化や災害復旧を実現します。

ログストリームにはロール情報があり、LEADERかFOLLOWERかが記録されています。oceanbase.DBA_OB_LS_LOCATIONS ビューの ROLE フィールドを使用して確認できます。データパーティションは独立したロール情報を持たなくなり、所属するログストリームのロールによって決定されます。ログストリームのロールは選挙プロトコルによって決定されます。

ビュー oceanbase.DBA_OB_LS_LOCATIONS の詳細については、DBA_OB_LS_LOCATIONS を参照してください。

データパーティションからログストリームへのマッピングの確認

DBA_OB_TABLE_LOCATIONS ビューを使用すると、テナント内のデータパーティションからログストリームへのマッピングを確認できます。各データパーティションの各レプリカが1件のレコードとなり、そのデータパーティションの基本情報と所属するログストリームの情報が記録されています。

ビュー oceanbase.DBA_OB_TABLE_LOCATIONS の詳細については、DBA_OB_TABLE_LOCATIONS を参照してください。