カラムストアレプリカの使用|V4.4.2|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

カラムストアレプリカの使用

最終更新日：2026-06-15 02:31:30 更新

TP 強化型混合負荷（準リアルタイム意思決定分析）シナリオへの対応を満たすため、OceanBase データベースはカラムストアレプリカ（COLUMNSTORE、以下 C レプリカと略称）をサポートしています。ユーザーは C レプリカを独立したゾーンにデプロイできます。C レプリカ上では、すべてのユーザーテーブル（レプリケーションテーブルを含む、インデックステーブル、内部テーブル、システムテーブルを除く）がカラムストア形式で保存されます。OLAP 業務は独立したプロキシエントリポイントを介して C レプリカにアクセスし、弱い読み取り（weak read）方式で意思決定分析業務を実行します。

注意事項

Cコピーを使用する際には、以下の点に注意してください：

V4.3.5 BP1バージョン以降、複数のCコピーのデプロイがサポートされていますが、最大で3つのCコピーをデプロイすることを推奨します。
CコピーとFまたはRコピー間の相互変換はサポートされていません。
Cコピーへのアクセスには独立したODPのデプロイが必要なため、Cコピーが存在するZoneにはCコピーのみをデプロイすることを推奨します。同時に、ODPをデプロイする際には、そのバージョンがODP V4.3.2以上である必要があります。
F/Rコピー上のクエリはCコピーに転送することができません。逆に、Cコピー上のユーザーテーブルクエリもF/Rコピーに転送することはできず、そうするとエラーが発生します。
Cコピーがデプロイされているクラスタでは、DDL操作の実行時にCPU、メモリ、ディスク、I/Oなどのリソース使用量に影響が出ます。
CコピーのメジャーコンパクションはF/Rコピーのメジャーコンパクションよりも遅くなります。Cコピーのメジャーコンパクションが完了していない場合、新しいテナントレベルのメジャーコンパクションを開始することはできません。手動でメジャーコンパクションをトリガーする前に、CDB_OB_ZONE_MAJOR_COMPACTIONまたはDBA_OB_ZONE_MAJOR_COMPACTIONビューを確認し、前回のすべてのコピーのメジャーコンパクションが完了しているかどうかを確認することを推奨します。

メジャーコンパクション状況の詳細な確認方法については、メジャーコンパクション情報の確認を参照してください。
物理復元はCコピーの復元をサポートしていません。指定テナントのローカリティを指定する際にCコピーを指定した場合、復元操作は失敗します。
プライマリデータベースにCコピーがデプロイされていない場合、スタンバイデータベースにもCコピーのデプロイは推奨されません。

CコピーのデプロイとODPの設定

以下では、OceanBaseクラスタにODPをデプロイし、Cコピーにアクセスするための設定方法について説明します。

ステップ1：Cレプリカのデプロイ

クラスタ内にCレプリカをデプロイするには、テナントのローカリティにCレプリカを指定するだけです。主なシナリオは以下の2つです：

テナント作成時にCレプリカを指定する
テナントのローカリティを変更してCレプリカを追加する

テナント作成時にCレプリカを指定する

既にデプロイ済みのクラスタがあり、そのクラスタのデプロイメントモードが2F1A（2レプリカ + 1アービトレーションサービス）であると仮定します。クラスタ内の3つのゾーンはそれぞれzone1、zone2、zone3で、アービトレーションサービスはzone3にデプロイされています。このクラスタ上にCレプリカを含むテナントを作成する手順は以下のとおりです：

現在のクラスタネットワークと相互接続可能なマシンを見つけ、そのマシンにODPをデプロイします。

リソース競合を防ぐため、ODPは単独のマシンにデプロイすることを推奨します。ODPのデプロイ時には、バージョンがODP V4.3.2以上である必要があります。

テナント用のリソースユニットunit1を作成します。

obclient [oceanbase]> CREATE RESOURCE UNIT unit1, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;

テナント用のリソースプールpool1を作成し、リソースユニットとしてunit1を指定します。

obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1', UNIT_NUM = 1, ZONE_LIST = ('zone1','zone2','zone3');

テナントtenant_cを作成し、そのLocalityをF@zone1,F@zone2,C@zone3に指定します。
```
obclient [oceanbase]> CREATE TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,C@zone3', primary_zone='zone1;zone2,zone3', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes = '%';
```
この例では、作成されるテナントはデフォルトでMySQL互換モードのテナントです。Oracle互換モードのテナントを作成する場合は、システム変数ob_compatibility_modeで明示的にob_compatibility_mode='oracle'を指定する必要があります。

テナントのローカリティを変更してCレプリカを追加する

現在のクラスタに tenant_c という名前のテナントがあり、そのローカリティは F@zone1,F@zone2,F@zone3 で、テナントのリソースプールは pool1 です。ZONE_LIST の範囲は 'zone1','zone2','zone3' です。このテナントにCレプリカを追加するには、Zone4 を追加し、テナントのローカリティを F@zone1,F@zone2,F@zone3,C@zone4 に変更します。手順は以下のとおりです：

クラスタに新しいゾーン zone4 を追加します。ゾーンの追加手順の詳細については、ゾーンの追加を参照してください。
zone4 内にノードを追加します。ノードの追加手順の詳細については、ノードの追加を参照してください。
現在のクラスタネットワークと相互接続可能なマシンを見つけ、そのマシンにODPをデプロイします。

リソース競合を防ぐため、ODPは単独のマシンにデプロイすることを推奨します。ODPのデプロイ時には、バージョンがODP V4.3.2以上である必要があります。

リソースユニット unit2 を作成します。

obclient [oceanbase]> CREATE RESOURCE UNIT unit2, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;

リソースプール pool2 を作成し、リソースユニットとして unit2 を指定します。

obclient [oceanbase]> CREATE RESOURCE POOL pool2 UNIT = 'unit2', UNIT_NUM = 1, ZONE_LIST = ('zone4');

テナントにリソースプール pool2 を追加します。

obclient [oceanbase]> ALTER TENANT tenant_c RESOURCE_POOL_LIST = ('pool1','pool2');

テナントのローカリティを F@zone1,F@zone2,F@zone3,C@zone4 に変更します。

obclient [oceanbase]> ALTER TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,F@zone3,C@zone4';

ステップ2：ルーティング転送ポリシーと弱い整合性読み取りの設定

Cコピーをデプロイした後、ルーティング転送ポリシーと弱い整合性読み取りを設定する必要があります。これにより、OLAPリクエストが自動的に弱い整合性読み取りに変換され、対応するCコピーに転送されることが保証されます。

root@proxysysユーザーで、CコピーにアクセスするためのODPにログインします。

接続例：
```
[admin@obtest ~]$ obclient -uroot@proxysys -h10.10.10.1 -P2883 -p
```
以下のステートメントを実行して、ルーティング転送ポリシーと弱い整合性読み取りを設定します。

次の2種類の構成パラメータの組み合わせがサポートされており、どちらか一方を選択して設定することができます。
- 方法1
  - SQLリクエストを読み取り専用タイプに設定します。
```
obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0;
```
  - SQLリクエストを弱い整合性読み取りに設定します。
```
obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;
```
  - 弱い整合性読み取りの場合、ODPのすべてのリクエストをCコピーが存在するZoneにのみルーティングし、同時にCコピーのクエリプランを生成します。
    
    例えば、Cコピーが存在するZoneはzone4です。
```
obclient> ALTER PROXYCONFIG SET proxy_primary_zone_name='zone4';
```
```
obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';
```
- 方法2
  - SQLリクエストを読み取り専用タイプに設定します。
```
obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0;
```
  - SQLリクエストを弱い整合性読み取りに設定します。
```
obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;
```
  - 弱い整合性読み取りの場合、すべてのリクエストをCコピーにのみルーティングし、同時にCコピーのクエリプランを生成します。
```
obclient> ALTER PROXYCONFIG SET route_target_replica_type = 'ColumnStore';
```
```
obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';
```
  - 弱い整合性読み取りの場合、すべてのリクエストはレプリカからのみ選択され、すべてのレプリカが利用不可な場合は、クライアントとの接続を切断します。
```
obclient> ALTER PROXYCONFIG SET proxy_route_policy='TARGET_REPLICA_TYPE_FOLLOWER_ONLY';
```

変更が成功した後、以下のステートメントを使用して、変更結果を確認します。

obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_only';

obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_consistency';

obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_primary_zone_name';

obclient> SHOW PROXYCONFIG ALL LIKE 'init_sql';

obclient> SHOW PROXYCONFIG ALL LIKE 'route_target_replica_type';

obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_route_policy';

設定が成功すると、OLAP業務において、ユーザーはこの独立したODPを通じてクエリリクエストをCコピーに定向し、カラムストアのバッチ処理の利点を活用してクエリを高速化できます。また、既存のOLTP業務に影響を与えません。

Cレプリカ上で一時的に行ストアとなるシナリオ

OceanBaseデータベースでは、テーブル作成時に行ストアテーブルとして設定された場合、システムはCレプリカ上に対応する純粋なカラムストアテーブルを作成します。テーブル作成時にカラムストアテーブルとして設定された場合、Cレプリカ上のストレージ方式はFレプリカと一致します。したがって、Cレプリカは、Fレプリカ上の行ストアユーザーテーブルのユーザーパーティションをカラムストアに変換する役割のみを担い、この記述は「最終的」な状態がカラムストアであることを示しています。Cレプリカ上では、必ずしも常にパーティションがカラムストア形式であるわけではありません。以下のシナリオでは、Cレプリカ上のユーザーテーブルのパーティションは一時的に行ストアとなり、システムが自発的に行から列への変換タスクをスケジュールし、最新のベースラインデータをカラムストアに変換する必要があります。

シナリオ	説明
レプリカの補完（レプリカの追加）	Localityを変更して`F@z1, F@z2`から`F@z1, F@z2, C@z3`に変更する例を挙げる：行ストアベースラインをソース側（FレプリカまたはRレプリカ）からターゲット側（Cレプリカ）に移行する際、まず行ストアをCレプリカにコピーし、そのTabletに対して行から列への変換を試みます。行から列への変換も特殊なメジャーコンパクションの一種であるため、試行が複数回失敗した場合（例：DAGスケジューラーのキューがいっぱい、I/O負荷が高い、ディスク容量不足など）、システムは行ストアに基づく弱い読み取りクエリを提供します。
ログストリームの再構築	Cレプリカ上のログストリームのRebuildがトリガーされると、システムはソース側から対応するベースラインをCレプリカに取得します。ベースラインデータが行ストアの場合は、一時的に行ストアとして保持され、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換されます。
レプリカ補完とOffline DDLの同時実行シナリオ	Cレプリカがログストリームメンバーリストに含まれている場合、Offline DDLを実行すると、システムはCレプリカ上に直接列ストアベースラインを構築します。しかし、レプリカ補完とOffline DDLが同時に発生すると、CレプリカはDDLタスクを実行するログストリームのリーダーに対して不可視となります。この場合、システムはCレプリカ上にまず行ストアのベースラインを構築し、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換します。
フルダイレクトロード	フルダイレクトロードは現在、まずCレプリカに行ストアをインポートし、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換することのみをサポートしています。
テーブルレベルの復元	現在の列ストアテーブルはテーブルレベルの復元をサポートしていないため、Cレプリカ上のテーブルレベルの復元は、まず行ストアに復元し、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換することのみをサポートします。

上記のシナリオでは、行ストアからカラムストアへの変換プロセス中、現在のオプティマイザーが生成するのはカラムストアのクエリ計画ですが、実際に実行されるのは依然として行ストアのベースラインに対するクエリです。ユーザーはビューCDB_OB_CS_REPLICA_STATS（システムテナント）およびDBA_OB_CS_REPLICA_STATS（ユーザーテナント）を使用して、Cレプリカの利用可能情報および行から列への変換の進捗状況を確認できます。行から列への変換タスクが完全に終了した後、Cレプリカ上でクエリを実行してください。

sysテナント内で、すべてのテナントのCレプリカログストリームにおけるTabletの行から列への変換進捗を確認する例は以下のとおりです：

obclient[oceanbase]> SELECT * FROM oceanbase.CDB_OB_CS_REPLICA_STATS;

クエリ結果は次のとおりです：

+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
| TENANT_ID | SVR_IP         | SVR_PORT | LS_ID | TOTAL_TABLET_CNT | AVAILABLE_TABLET_CNT | TOTAL_MACRO_BLOCK_CNT | AVAILABLE_MACRO_BLOCK_CNT | AVAILABLE |
+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
|      1004 | xx.xxx.xxx.212 |    63000 |  1001 |             1019 |                 1019 |                 10706 |                     10706 | TRUE      |
|      1006 | xx.xxx.xxx.212 |    63000 |  1001 |              133 |                  133 |                   875 |                       875 | TRUE      |
+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
2 rows in set

最初のクエリ結果から、テナントIDが1004のテナントのCレプリカが配置されているサーバーはxx.xxx.xxx.212、ポート番号は63000であることがわかります。CレプリカログストリームのIDは1001、現在カラムストアに変換する必要があるパーティションの総数は1019、利用可能なパーティションの総数も1019です。現在のベースラインマクロブロックの総数は10706、利用可能なベースラインマクロブロックの総数も10706です。ユーザーはAVAILABLE_TABLET_CNT / TOTAL_TABLET_CNTまたはAVAILABLE_MACRO_BLOCK_CNT / TOTAL_MACRO_BLOCK_CNTを用いて、行から列への変換の進捗を大まかに推定できます。ログストリーム上のすべてのTabletが利用可能になった場合にのみ、そのログストリームは完全に利用可能となります。