レプリカの概念
レプリカはOceanBaseデータベースのストレージエンジンにおける概念であり、同一のデータを異なるノードにコピーしたものを指します。ここでのデータとはユーザーレベルの概念です。
OceanBaseデータベースの観点から言えば、これはデータパーティションを指します。各データパーティションはテナントのローカリティ属性に基づいて複数のレプリカが冗長化されており、優れた水平スケーラビリティとより高度な災害復旧能力を提供します。
データパーティションとは、一定のテーブル作成ルールに従って、テーブルまたはインデックスを複数のより小さく管理しやすい部分に分割することを指します。各データパーティションは独立したオブジェクトであり、独自の名前とオプションのストレージ特性を持ちます。
説明
OceanBaseデータベースはマルチレプリカアーキテクチャで知られており、Paxosプロトコルに基づくマルチレプリカアーキテクチャは高可用性の基盤となっています。マルチレプリカにおける「レプリカ」とは本質的には同一のデータを異なるノードにコピーしたものであり、データはOceanBaseデータベースではデータパーティション、ログストリーム、Unit、テナントなど、複数のレベルで格納されます。一般的に「レプリカ」と言及する場合、多くは「データパーティションのレプリカ」を指します。ただし、文脈によって「レプリカ」が異なるデータベースエンティティを指す場合があるため注意が必要です。
レプリカの役割
レプリカはOceanBaseデータベースの可用性とフォールトトレランスを向上させます。レプリカは異なる地理的場所に配置され、ネットワーク障害やデータセンター障害に対応します。
OceanBaseデータベースは、パーティションレプリケーションやログ同期などの方法でデータを複数のレプリカに複製し、データ損失を防ぎます。これにより、少数のレプリカに障害が発生した場合でも、OceanBaseデータベースはロスレスのデータベースサービスを提供し続けることが保証されます。
レプリカの種類
OceanBaseデータベースのストレージエンジンは階層型LSM-Tree構造を採用しており、データは大きく二つに分かれています：ベースラインデータと増分データです。
ベースラインデータはディスクに永続化されるデータであり、一度生成されると変更されることはありません。これを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です。フル機能レプリカとは異なり、読み取り専用レプリカは読み取り機能のみを提供し、書き込み機能は提供しません。ログストリームのFollowerレプリカとしてのみ機能し、選挙やログの投票には参加せず、ログストリームのLeaderレプリカに選出されることもありません。
読み取り専用レプリカはオプションのレプリカであり、ユーザーはビジネスの実際のニーズに応じてデプロイするかどうかを選択できます。読み取り専用レプリカの詳細については、読み取り専用レプリカを参照してください。
カラムストアレプリカ
カラムストアレプリカの名前は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ノードに自動的に1つのレプリカをデプロイし、理想的な状況下では任意のOBServerノードでレプリケーションテーブルに対する強整合性読み取りを提供できるようにします。
一般的に、整合性プロトコルの投票に参加するレプリカが多すぎると、多数派を形成するのに必要な時間が長くなります。テナント内のOBServerノードが多い場合、すべてのOBServer上のレプリカに投票参加を求めることは現実的ではありません。そのため、ブロードキャストログストリームでは、投票に参加する必要のないOBServerにはRレプリカ（READONLYレプリカ、読み取り専用レプリカ）をデプロイし、投票に参加する必要のあるOBServerノードには通常のFレプリカ（FULLレプリカ、フル機能レプリカ）をデプロイします。
ブロードキャストログストリームと通常のログストリームのレプリカの違いは以下の通りです：
通常のログストリームでは、各Zoneには1つのレプリカしか存在できず、そのレプリカタイプはLocalityで指定されたレプリカタイプと一致している必要があります。
ブロードキャストログストリームでは、各Zone内において、Localityで記述されているそのZoneのレプリカタイプに加え、そのZone内で当該テナントのUnitリソースを持つ他のマシンにも、それぞれ1つの読み取り専用レプリカが配置されます。Localityでレプリカタイプが指定されていないZoneには、レプリカは配置されません。
ブロードキャストログストリームの制限事項は以下の通りです：
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 を参照してください。