テナントのスケールアウトとスケールインは、本質的にはテナントのサービス能力（計算能力およびストレージ容量を含む）を向上または低下させることです。単一ノードのサービス能力を向上させるか、サービスノードを追加することで実現できます。本記事では、Unit Numberを変更することでサービスノードを増減し、テナント全体のサービス能力を向上または低下させる方法、つまりテナントのスケールアウトまたはスケールインの実現方法について説明します。
Unit Numberの変更には、Unit Numberを大きくする場合と小さくする場合が含まれます。
背景
現在のバージョンでは、OceanBaseデータベースはテナントの同種ゾーンモードと異種ゾーンモードをサポートしています。
同種ゾーンモードでは、テナント内の各ゾーンのUnit数が常に一致している必要があります。また、各ゾーンのUnitを一元的に管理するため、システムはUnit Groupメカニズムを導入しています。つまり、異なるゾーン間で同じ番号(
UNIT_GROUP_ID)を持つUnitは、同一のUnit Groupに属します。同種ゾーンモードのテナントでは、Unit Numberを増減することは、本質的にはUnit Group単位でUnitを作成および削除することになります。異種ゾーンモードでは、テナント内の各ゾーンの
UNIT_NUMは同じでも異なっても構いませんが、一つのテナントのすべてのZoneで使用できるUNIT_NUMの種類は最大2種類です。ログストリームの分散はUnit Groupに束縛されなくなり、各Zoneのレプリカは対称的なUnit上に配置する必要がなくなりました。異種ゾーンモードのテナントでは、テナント全体のUnit Numberを一括で増減するほかに、複数のリソースプールがある場合は、特定のリソースプールのUnit Numberを個別に増減することで、リソースプール単位でのスケーリングを実現できます。
注意
通常、既存のテナントやアップグレード後のテナントは、デフォルトで同種ゾーンモードに設定されています。異種ゾーンモードを有効にするには、テナントレベルのパラメータzone_deploy_modeの値をhetero(異種ゾーンモード)に変更する必要があります。変更後は、homo(同種ゾーンモード)に戻すことはできません。
前提条件
テナントのスケールアウトおよびスケールイン操作を実施する前に、以下の操作を行う必要があります：
テナント内のロードバランシングポリシーの設定
テナント内のロードバランシングポリシーは、テナントレベルの構成パラメータ
enable_rebalanceとenable_transferによって共同で制御されます。パラメータ
enable_rebalanceは、システムテナントではテナント間のロードバランシングを有効にするかどうかを、ユーザーテナントではテナント内のロードバランシングを有効にするかどうかを制御します。テナントのスケールアウト/スケールイン操作時には、テナント内のロードバランシングを有効にする必要があります。この構成パラメータのデフォルト値はtrueで、ロードバランシングが有効であることを示します。設定後はOBServerノードを再起動する必要がなく、即時に反映されます。パラメータ
enable_transferは、テナントのTransfer機能を有効にするかどうかを制御します。デフォルト値はtrueです。設定後はOBServerノードを再起動する必要がなく、即時に反映されます。具体的には：パラメータ
enable_rebalanceの値がfalseの場合、パラメータenable_transferの値がtrueであってもfalseであっても、システムは自動ロードバランシングを行いません。パラメータ
enable_rebalanceの値がtrueかつenable_transferの値もtrueの場合、テナントのスケールアウト/スケールイン操作時にシステムが自動的にパーティションの分散を調整し、ロードバランシングを実現することを意味します。パラメータ
enable_rebalanceの値がtrueかつenable_transferの値がfalseの場合、テナントのスケールアウト/スケールイン操作時にシステムがTransfer操作を開始できず、限定的なロードバランシングはログストリーム移行によってのみ実現可能であることを意味します。
設定方法は以下の通りです：
システムテナントで指定テナントのロードバランシングポリシーを設定
システムテナントで指定テナントのテナント内ロードバランシングおよびテナントのTransfer機能を有効にする
ALTER SYSTEM SET enable_rebalance = true TENANT = 'tenant_name';ALTER SYSTEM SET enable_transfer = true TENANT = 'tenant_name';上記のステートメントは、指定テナントの
enable_rebalanceおよびenable_transferパラメータの値をtrueに設定することを示しています。システムテナントですべてのユーザーテナント（
sysテナントおよびMetaテナントを除く）のテナント内ロードバランシングおよびテナントのTransfer機能を有効にするALTER SYSTEM SET enable_rebalance = true TENANT = all_user;ALTER SYSTEM SET enable_transfer = true TENANT = all_user;または
ALTER SYSTEM SET enable_rebalance = true TENANT = all;ALTER SYSTEM SET enable_transfer = true TENANT = all;上記のステートメントは、すべてのユーザーテナントの
enable_rebalanceおよびenable_transferパラメータの値をtrueに設定することを示しています。説明
OceanBaseデータベースでは、バージョンV4.2.1以降、
TENANT = all_userとTENANT = allの意味は同じです。適用範囲をすべてのユーザーテナントに設定する場合は、TENANT = all_userの使用を推奨します。TENANT = allは今後廃止されます。
ユーザーテナントで自身のテナントのロードバランシングポリシーを設定
MySQLモードOracleモードMySQLテナントで、そのテナント内のロードバランシングおよびテナント下のTransfer機能を有効にするステートメントは以下のとおりです：
ALTER SYSTEM SET enable_rebalance = true;ALTER SYSTEM SET enable_transfer = true;Oracleテナントで、そのテナント内のロードバランシングおよびテナント下のTransfer機能を有効にするステートメントは以下のとおりです：
ALTER SYSTEM SET enable_rebalance = 'true';ALTER SYSTEM SET enable_transfer = 'true';
enable_rebalanceおよびenable_transferパラメータの詳細については、enable_rebalanceおよびenable_transferを参照してください。アイドル状態のリソースプールは使用中のリソースとしてカウントされるため、スケールアウト前にテナントが削除される場合は、対応するリソースプールも一緒に削除してリソースを解放することを推奨します。
リソースプールの削除に関する操作については、リソースプールの削除を参照してください。
テナントのスケールインを行う前に、テナントが使用中のメモリを解放するため、一度ダンプを実行することを推奨します。
ダンプを手動でトリガーする操作については、手動でダンプをトリガーするを参照してください。
テナントのスケールアウト/スケールイン操作を実行する前に、期待される効果を得るために、まずテナントのリソース計画を立てることを推奨します。
テナントのスケールアウト/スケールインのリソース計画に関する詳細な操作については、テナントのスケールアウト/スケールインのリソース計画を参照してください。
注意点
Unit Numberの調整によるテナントのスケーリングを行う際は、以下の点に注意してください：
スケーリング中は、テナントのローカリティを変更することは禁止されています。
スケーリング中は、テナントのリソースプールの
ZONE_LIST範囲を拡大することは禁止されています。スケーリング中は、テナントに新しいリソースプールを追加することは禁止されています。
スケーリング中は、リソースプールのメジャーコンパクションを実行することは禁止されています。
スケーリング中は、
DELETING状態のUnitに対して移行操作を実行することは禁止されています。
ユニット数の増加
テナントのすべてのリソースプールのUnit Numberを増やす
同種ゾーンモードのテナントでも異種ゾーンモードのテナントでも、ALTER RESOURCE TENANTステートメントを使用して、テナントのすべてのリソースプールのUnit Numberを一括して増やすことができます。以下では、テナントmysql001のすべてのリソースプールのUnit Numberを増やす例を挙げて操作方法を説明します。
rootユーザーでクラスタのsysテナントにログインします。obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> use oceanbase;テナント
mysql001の情報を確認し、そのTENANT_IDを取得します。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, TENANT_ROLE, UNIT_NUM, ZONE_UNIT_NUM_LIST FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';クエリ結果は次のとおりです：
+-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | TENANT_ID | TENANT_NAME | TENANT_TYPE | PRIMARY_ZONE | LOCALITY | TENANT_ROLE | UNIT_NUM | ZONE_UNIT_NUM_LIST | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | 1006 | mysql001 | USER | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | PRIMARY | 1 | zone1:1,zone2:1,zone3:1 | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ 1 row in setクエリ結果によると、テナントの
TENANT_IDは1006であり、このテナントの各ゾーンにおけるUnit Numberは1:1:1です。テナント
mysql001が保有するUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1013 | 1006 | ACTIVE | 1002 | 1023 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1023 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1023 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 3 rows in setクエリ結果から、テナント
mysql001は各ゾーンに1つずつUnitを持ち、これら3つのUnitが対応するUNIT_GROUP_IDが同じであることがわかります。テナント
mysql001のUNIT_NUMを2に変更します。obclient(root@sys)[oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 2;コマンド実行が成功した後、現在のUnitの状態を確認します。
obclient> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1013 | 1006 | ACTIVE | 1002 | 1024 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1024 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1024 | zone3 | 1001 | | 1025 | 1006 | ADDING | 1001 | 1025 | zone1 | 1001 | | 1026 | 1006 | ADDING | 1002 | 1025 | zone2 | 1001 | | 1027 | 1006 | ADDING | 1003 | 1025 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 6 rows in set新規追加されるUnitはすべて
ADDING状態であることが確認できます。内部のバランシングが完了すると、Unitの状態はADDING状態からACTIVE状態に変わります。注意
- OceanBaseデータベースの以前のバージョンでは、
UNIT_NUMの拡張は同期プロセスでしたが、現在のバージョンでは、UNIT_NUMの拡張は非同期プロセスとなりました。新規追加されるUnitはADDING状態です。 - 拡張プロセス中（新規追加されるUnitがまだ
ADDING状態の場合）、ロールバック操作をサポートします。例えば、この例では、
ALTER RESOURCE TENANT mysql001 UNIT_NUM = 1;ステートメントを実行して、UNIT_NUMを元の値に戻すことができます。ロールバック時、元のADDING状態のUnitは直接DELETING状態に変わります。なお、ロールバック操作を実行する際、指定したUNIT_GROUPを削除する方法でロールバックすることはサポートされていないため、システムは自動的にADDING状態のUnitを選択して削除します。 - 拡張プロセス終了前は、ロールバック操作のみを許可し、
UNIT_NUMを他の値に変更することは禁止されています。
- OceanBaseデータベースの以前のバージョンでは、
Unit Numberを増やすタスクの実行状態を確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE JOB_TYPE='ALTER_RESOURCE_TENANT_UNIT_NUM' AND TENANT_ID = 1006;クエリ結果は次のとおりです：
+--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | JOB_ID | JOB_TYPE | JOB_STATUS | RESULT_CODE | PROGRESS | START_TIME | MODIFY_TIME | TENANT_ID | SQL_TEXT | EXTRA_INFO | RS_SVR_IP | RS_SVR_PORT | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | 26 | ALTER_RESOURCE_TENANT_UNIT_NUM | SUCCESS | 0 | 100 | 2025-06-18 10:10:19.430962 | 2025-06-18 10:10:54.229794 | 1006 | ALTER RESOURCE TENANT mysql001 UNIT_NUM = 2 | new unit num: '2' | 6.xx.xxx.xxx | 29700 | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ 1 row in setクエリ結果において、以下のフィールドに基づいて、対応するタスクレコードを見つけます：
START_TIME：タスクの開始時間。SQL_TEXT：タスクに対応するSQLステートメント。EXTRA_INFO：変更前後のUnit Number数。
対応する変更レコードにおいて
JOB_STATUSの値がSUCCESSの場合、Unit Numberを増やすタスクの実行が成功したことを示します。ビュー
DBA_OB_TENANT_JOBSの詳細なフィールド説明については、DBA_OB_TENANT_JOBSを参照してください。テナント
mysql001の変更後のUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1013 | 1006 | ACTIVE | 1002 | 1024 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1024 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1024 | zone3 | 1001 | | 1025 | 1006 | ACTIVE | 1001 | 1025 | zone1 | 1001 | | 1026 | 1006 | ACTIVE | 1002 | 1025 | zone2 | 1001 | | 1027 | 1006 | ACTIVE | 1003 | 1025 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 6 rows in set
上記の例により、テナントmysql001のすべてのリソースプールのUnit Numberを1から2に変更しました。変更前はテナントが各ゾーンに1つのUnitを持っていましたが、変更後はテナントが各ゾーンに2つのUnitを持つようになり、テナントの拡張が実現されました。
テナントの単一リソースプールのUnit Numberを増やす
異種ゾーンモードのテナントでは、複数のリソースプールがある場合、ALTER RESOURCE POOLステートメントを使用して、テナントの特定のリソースプールのUnit Numberを個別に増やすこともできます。同種ゾーンモードのテナントはこの方法をサポートしていません。
以下では、テナントmysql001のリソースプールpool2のUnit Numberを増やす例を挙げて、操作手順を説明します。
rootユーザーでクラスタのsysテナントにログインします。obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> use oceanbase;テナント
mysql001の情報を確認し、そのTENANT_IDを取得します。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, TENANT_ROLE, UNIT_NUM, ZONE_UNIT_NUM_LIST FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';クエリ結果は次のとおりです：
+-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | TENANT_ID | TENANT_NAME | TENANT_TYPE | PRIMARY_ZONE | LOCALITY | TENANT_ROLE | UNIT_NUM | ZONE_UNIT_NUM_LIST | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | 1006 | mysql001 | USER | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | PRIMARY | 2 | zone1:2,zone2:2,zone3:2 | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ 1 row in setクエリ結果によると、テナントの
TENANT_IDは1006であり、このテナントの各ゾーンにおけるUnit Numberは2:2:2です。現在のテナントのリソース構成情報を確認します。
obclient(root@sys)[oceanbase]> SELECT c.TENANT_ID, e.TENANT_NAME, concat(c.NAME, ': ', d.NAME) `pool:conf`,c.ZONE_LIST, concat(c.UNIT_COUNT, ' unit: ', d.min_cpu, 'C/', ROUND(d.MEMORY_SIZE/1024/1024/1024,0), "G") unit_info FROM oceanbase.DBA_OB_RESOURCE_POOLS c, oceanbase.DBA_OB_UNIT_CONFIGS d, oceanbase.DBA_OB_TENANTS e WHERE c.UNIT_CONFIG_ID=d.UNIT_CONFIG_ID AND c.TENANT_ID=e.TENANT_ID AND c.TENANT_ID=1006;クエリ結果は次のとおりです：
+-----------+-------------+------------------+-----------+---------------+ | TENANT_ID | TENANT_NAME | pool:conf | ZONE_LIST | unit_info | +-----------+-------------+------------------+-----------+---------------+ | 1006 | mysql001 | pool3: test_unit | zone3 | 2 unit: 1C/8G | | 1006 | mysql001 | pool2: test_unit | zone2 | 2 unit: 1C/8G | | 1006 | mysql001 | pool1: test_unit | zone1 | 2 unit: 1C/8G | +-----------+-------------+------------------+-----------+---------------+ 3 rows in setクエリ結果から、テナント
mysql001にはpool1、pool2、pool3の合計3つのリソースプールがあり、それぞれzone1、zone2、zone3に配置されていることがわかります。実際のニーズに応じて、テナント
mysql001のリソースプールpool2のUNIT_NUMを3に変更します。obclient(root@sys)[oceanbase]> ALTER RESOURCE POOL pool2 UNIT_NUM = 3;コマンド実行が成功した後、現在のUnitの状態を確認します。
obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1013 | 1006 | ACTIVE | 1002 | 1026 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1024 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1024 | zone3 | 1001 | | 1025 | 1006 | ACTIVE | 1001 | 1025 | zone1 | 1001 | | 1026 | 1006 | ACTIVE | 1002 | 1027 | zone2 | 1001 | | 1027 | 1006 | ACTIVE | 1003 | 1025 | zone3 | 1001 | | 1028 | 1006 | ADDING | 1002 | 1028 | zone2 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 7 rows in set新規追加されるUnitは
ADDING状態であることが確認できます。内部のバランシングが完了すると、Unitの状態はADDING状態からACTIVE状態に変わります。注意
- OceanBaseデータベースの以前のバージョンでは、
UNIT_NUMの拡張は同期プロセスでしたが、現在のバージョンでは、UNIT_NUMの拡張は非同期プロセスに変更されました。新規追加されるUnitはADDING状態です。 - 拡張プロセス中（新規追加されるUnitがまだ
ADDING状態の場合）、ロールバック操作をサポートします。例えば、この例では、
ALTER RESOURCE POOL pool2 UNIT_NUM = 2;ステートメントを実行して、UNIT_NUMを元の値に戻すことができます。ロールバック時、元のADDING状態のUnitは直接DELETING状態に変わります。なお、ロールバック操作を実行する際、指定したUnitを削除する方法でロールバックすることはサポートされていません。システムは自動的にADDING状態のUnitを選択して削除します。 - 拡張プロセス終了前は、ロールバック操作のみを許可し、
UNIT_NUMを他の値に変更することは禁止されています。
- OceanBaseデータベースの以前のバージョンでは、
Unit Numberを増やすタスクの実行状態を確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE JOB_TYPE='ALTER_RESOURCE_TENANT_UNIT_NUM' AND TENANT_ID=1006;クエリ結果は次のとおりです：
+--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | JOB_ID | JOB_TYPE | JOB_STATUS | RESULT_CODE | PROGRESS | START_TIME | MODIFY_TIME | TENANT_ID | SQL_TEXT | EXTRA_INFO | RS_SVR_IP | RS_SVR_PORT | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | 27 | ALTER_RESOURCE_TENANT_UNIT_NUM | INPROGRESS | NULL | 0 | 2025-06-18 11:02:52.005261 | 2025-06-18 11:02:52.005261 | 1006 | ALTER RESOURCE POOL pool2 UNIT_NUM = 3 | new unit num: '3' | 6.xx.xxx.xxx | 29700 | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ 1 row in setクエリ結果において、以下のフィールドに基づいて対応するタスクレコードを見つけます：
START_TIME：タスクの開始時間。SQL_TEXT：タスクに対応するSQLステートメント。EXTRA_INFO：変更前後のUnit Numberの数。
対応する変更レコードにおいて、
JOB_STATUSの値がSUCCESSの場合、Unit Numberを増やすタスクの実行が成功したことを意味します。ビュー
DBA_OB_TENANT_JOBSの詳細なフィールド説明については、DBA_OB_TENANT_JOBSを参照してください。テナント
mysql001の変更後のUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1013 | 1006 | ACTIVE | 1002 | 1026 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1024 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1024 | zone3 | 1001 | | 1025 | 1006 | ACTIVE | 1001 | 1025 | zone1 | 1001 | | 1026 | 1006 | ACTIVE | 1002 | 1027 | zone2 | 1001 | | 1027 | 1006 | ACTIVE | 1003 | 1025 | zone3 | 1001 | | 1028 | 1006 | ADDING | 1002 | 1028 | zone2 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 7 rows in set
上記の例により、テナントmysql001のリソースプールpool2のUnit Numberを2から3に変更しました。変更前はテナントの各ゾーンにおけるUnit数が2でした。変更後は、テナントのzone1およびzone3のUnit数は引き続き2ですが、zon2のUnit数が3に変わり、テナントの拡張が実現されました。
ユニット数を減らす
注意点
テナントのUnit Numberを小さくする前に、GTS専用モードが有効になっていないか確認する必要があります。GTS専用モードは、テナントレベルの構成パラメータenable_gts_standaloneで制御され、デフォルト値はFalse、つまり無効状態です。
GTS専用モードが有効な場合は、以下の点に注意してください：
GTS専用モードが有効になると、テナント内の各ゾーンの
UNIT_NUMが2以上である必要があります。テナントのいずれかのゾーンをUNIT_NUMが2未満にスケールインした場合、システムはエラーを返します。指定したUNIT_LISTまたはUnit Groupを削除してUnit Numberを小さくする際、GTS専用モードのUnitまたはUnit Groupを指定して削除することはできません。そうした場合、システムはエラーを返します。
テナントのすべてのリソースプールのUnit Numberを小さくする
同種ゾーンモードまたは異種ゾーンモードのテナントについて、ALTER RESOURCE TENANTステートメントを使用して、テナントのすべてのリソースプールのUnit Numberを一括して小さくできます。以下では、テナントmysql001のすべてのリソースプールのUnit Numberを小さくする例を挙げて操作方法を説明します。
以下では、テナントmysql001のUnit Numberを小さくする例を挙げて操作方法を説明します。
rootユーザーでクラスタのsysテナントにログインします。obclient -h172.xxx.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> use oceanbase;テナント
mysql001の情報を確認し、そのTENANT_IDを取得します。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, TENANT_ROLE, UNIT_NUM, ZONE_UNIT_NUM_LIST FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';クエリ結果は次のとおりです：
+-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | TENANT_ID | TENANT_NAME | TENANT_TYPE | PRIMARY_ZONE | LOCALITY | TENANT_ROLE | UNIT_NUM | ZONE_UNIT_NUM_LIST | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | 1006 | mysql001 | USER | zone1;zone2,zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | PRIMARY | 3 | zone1:3,zone2:3,zone3:3 | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ 1 row in setクエリ結果によると、テナントの
TENANT_IDは1006であり、このテナントの各ゾーンにおけるUnit Numberはすべて3です。テナント
mysql001が保有するUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1001 | 1006 | ACTIVE | 1001 | 1018 | zone1 | 1001 | | 1005 | 1006 | ACTIVE | 1003 | 1018 | zone3 | 1001 | | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1007 | 1006 | ACTIVE | 1002 | 1018 | zone2 | 1001 | | 1011 | 1006 | ACTIVE | 1002 | 1019 | zone2 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1020 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+-------+----------------+ 9 rows in setクエリ結果から、テナント
mysql001は各ゾーンに3つのUnitを持っていることがわかります。そのうち、UNIT_IDが1001、1005、1007のUNIT_GROUP_IDはすべて1018であり、UNIT_IDが1006、1011、1012のUNIT_GROUP_IDはすべて1019、UNIT_IDが1013、1014、1015のUNIT_GROUP_IDはすべて1020です。テナント
mysql001のUNIT_NUMを2に変更します。Unitをランダムに削除することで
UNIT_NUMの数を減らします。同種ゾーンモードまたは異種ゾーンモードのテナントについて、以下のステートメントを使用して
UNIT_NUMの数を減らせます。obclient(root@sys)[oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 2;このステートメントを実行した後：
同種ゾーンモードのテナントの場合、例えばこの例では、テナントのすべてのリソースプールの
UNIT_NUMが3から2に変更されます。システムはUNIT_GROUP_IDが同じUnit Groupのセットをランダムに指定して削除します。異種ゾーンモードのテナントの場合、システムはランダムに選択したUNIT_LISTの1つを削除します。
指定された
UNIT_GROUPを削除することでUNIT_NUMの数を減らします同種ゾーンモードのテナントの場合、以下のステートメントを使用して
UNIT_NUMの数を減らすこともできますが、異種ゾーンモードのテナントはこのステートメントをサポートしていません。obclient(root@sys)[oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 2 DELETE UNIT_GROUP =(1018);このステートメントを実行した後、各ゾーンに3つのUnitがある場合、システムは指定されたUnit Group上のデータを他のUnit Groupに再配置した後、そのUnit Groupを削除します。
コマンドの実行が成功した後、現在のUnitの状態を確認します。
obclient> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果の例は次のとおりです：
+---------+-----------+----------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+----------+------------------+---------------+-------+----------------+ | 1001 | 1006 | DELETING | 1001 | 1018 | zone1 | 1001 | | 1005 | 1006 | DELETING | 1003 | 1018 | zone3 | 1001 | | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1007 | 1006 | DELETING | 1002 | 1018 | zone2 | 1001 | | 1011 | 1006 | ACTIVE | 1002 | 1019 | zone2 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1020 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+----------+------------------+---------------+-------+----------------+ 9 rows in set宜削除中のUnitは
DELETING状態であることが確認できます。注意
- OceanBaseデータベースでは、
UNIT_NUMのスケールダウンは非同期プロセスです。スケールダウン中（待機中のUnitは依然としてDELETING状態）、ロールバック操作をサポートします。例えば、この例では、
ALTER RESOURCE TENANT mysql001 UNIT_NUM = 3;ステートメントを実行してUNIT_NUMを元の値に戻すことができます。ロールバック時、元のDELETING状態のUnitは直接ADDING状態に変わります。 - スケールダウン中はロールバック操作のみをサポートし、
UNIT_NUMを他の値に変更することは禁止されています。
- OceanBaseデータベースでは、
Unit Numberを小さくするタスクの実行状態を確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE JOB_TYPE='ALTER_RESOURCE_TENANT_UNIT_NUM' AND TENANT_ID=1006;クエリ結果の例は次のとおりです：
+--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | JOB_ID | JOB_TYPE | JOB_STATUS | RESULT_CODE | PROGRESS | START_TIME | MODIFY_TIME | TENANT_ID | SQL_TEXT | EXTRA_INFO | RS_SVR_IP | RS_SVR_PORT | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | 25 | ALTER_RESOURCE_TENANT_UNIT_NUM | SUCCESS | 0 | 100 | 2025-06-18 10:06:15.648806 | 2025-06-18 10:08:39.969346 | 1006 | alter resource tenant mysql001 unit_num=2 | new unit num: '2' | 6.xx.xxx.xxx | 29700 | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ 1 row in setクエリ結果において、以下のフィールドに基づいて対応するタスクレコードを見つけます：
START_TIME：タスクの開始時間。SQL_TEXT：タスクに対応するSQLステートメント。EXTRA_INFO：変更前後のUnit Numberの数。
対応するタスクレコードの
JOB_STATUSの値がSUCCESSの場合、Unit Numberを小さくするタスクの実行は成功したことを意味します。ビュー
DBA_OB_TENANT_JOBSの詳細なフィールド説明については、DBA_OB_TENANT_JOBSを参照してください。テナント
mysql001の変更後のUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1011 | 1006 | ACTIVE | 1002 | 1019 | zone2 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1020 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+------+-----------------+ 6 rows in set
上記の例により、テナントmysql001のすべてのリソースプールのUnit Numberを3から2に変更しました。変更前は、テナントの各ゾーンのUnit数が3でした。変更後は、テナントの各ゾーンのUnit数が2となり、テナントのスケールダウンが実現されました。
テナントの単一リソースプールのUnit Numberを減らす
異種ゾーンモードのテナントでは、複数のリソースプールがある場合、ALTER RESOURCE POOLステートメントを使用して、テナントの特定のリソースプールのUnit Numberを個別に減らすこともできます。同種ゾーンモードのテナントはこの方法をサポートしていません。
以下では、テナントmysql001のリソースプールpool2のUnit Numberを減らす例を挙げて操作方法を説明します。
rootユーザーでクラスタのsysテナントにログインします。obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> use oceanbase;テナント
mysql001の情報を確認し、そのTENANT_IDを取得します。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, TENANT_ROLE, UNIT_NUM, ZONE_UNIT_NUM_LIST FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';クエリ結果は次のとおりです：
+-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | TENANT_ID | TENANT_NAME | TENANT_TYPE | PRIMARY_ZONE | LOCALITY | TENANT_ROLE | UNIT_NUM | ZONE_UNIT_NUM_LIST | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ | 1006 | mysql001 | USER | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | PRIMARY | 2 | zone1:2,zone2:2,zone3:2 | +-----------+-------------+-------------+--------------------+---------------------------------------------+-------------+----------+-------------------------+ 1 row in setクエリ結果によると、テナントの
TENANT_IDは1006であり、このテナントの各ゾーンにおけるUnit Numberは2:2:2です。現在のテナントのリソース構成情報を確認します。
obclient(root@sys)[oceanbase]> SELECT c.TENANT_ID, e.TENANT_NAME, concat(c.NAME, ': ', d.NAME) `pool:conf`,c.ZONE_LIST, concat(c.UNIT_COUNT, ' unit: ', d.min_cpu, 'C/', ROUND(d.MEMORY_SIZE/1024/1024/1024,0), "G") unit_info FROM oceanbase.DBA_OB_RESOURCE_POOLS c, oceanbase.DBA_OB_UNIT_CONFIGS d, oceanbase.DBA_OB_TENANTS e WHERE c.UNIT_CONFIG_ID=d.UNIT_CONFIG_ID AND c.TENANT_ID=e.TENANT_ID AND c.TENANT_ID=1006;クエリ結果は次のとおりです：
+-----------+-------------+------------------+-----------+---------------+ | TENANT_ID | TENANT_NAME | pool:conf | ZONE_LIST | unit_info | +-----------+-------------+------------------+-----------+---------------+ | 1006 | mysql001 | pool3: test_unit | zone3 | 2 unit: 1C/8G | | 1006 | mysql001 | pool2: test_unit | zone2 | 2 unit: 1C/8G | | 1006 | mysql001 | pool1: test_unit | zone1 | 2 unit: 1C/8G | +-----------+-------------+------------------+-----------+---------------+ 3 rows in setクエリ結果から、テナント
mysql001にはpool1、pool2、pool3の3つのリソースプールがあり、それぞれzone1、zone2、zone3に配置されていることがわかります。テナント
mysql001のUnit情報を確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+--------+------------------+---------------+-------+----------------+ | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1011 | 1006 | ACTIVE | 1002 | 1019 | zone2 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1020 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+--------+------------------+---------------+------+-----------------+ 6 rows in set実際のニーズに応じて、テナント
mysql001のリソースプールpool2のUNIT_NUMを1に変更します。ユニットをランダムに削除する方法で
UNIT_NUMの数を減らすobclient(root@sys)[oceanbase]> ALTER RESOURCE POOL pool2 UNIT_NUM = 1;指定したユニットを削除する方法で
UNIT_NUMの数を減らすobclient(root@sys)[oceanbase]> ALTER RESOURCE POOL pool2 UNIT_NUM = 1 DELETE UNIT=(1011);
コマンド実行後、現在のUnitの状態を確認します。
obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+----------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+----------+------------------+---------------+-------+----------------+ | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1011 | 1006 | DELETING | 1002 | 1019 | zone2 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1020 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+----------+------------------+---------------+------+-----------------+ 6 rows in set削除待ちのUnitが
DELETING状態であることが確認できます。注意
- OceanBaseデータベースでは、
UNIT_NUMのスケールダウンは非同期プロセスです。スケールダウン中（削除待ちのUnitがまだDELETING状態の場合）、ロールバック操作をサポートします。例えば、この例では
ALTER RESOURCE POOL pool2 UNIT_NUM = 2;ステートメントを実行してUNIT_NUMを元の値に戻すことができます。ロールバック時、元のDELETING状態のUnitは直接ADDING状態に変わります。 - スケールダウン中は、ロールバック操作のみをサポートし、
UNIT_NUMを他の値に変更することは禁止されています。
- OceanBaseデータベースでは、
Unit Numberを減らすタスクの実行状態を確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE JOB_TYPE='ALTER_RESOURCE_TENANT_UNIT_NUM' AND TENANT_ID=1006;クエリ結果は次のとおりです：
+--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | JOB_ID | JOB_TYPE | JOB_STATUS | RESULT_CODE | PROGRESS | START_TIME | MODIFY_TIME | TENANT_ID | SQL_TEXT | EXTRA_INFO | RS_SVR_IP | RS_SVR_PORT | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ | 24 | ALTER_RESOURCE_TENANT_UNIT_NUM | SUCCESS | 0 | 100 | 2025-06-18 09:39:34.319331 | 2025-06-18 09:40:30.439822 | 1006 | alter resource pool pool2 unit_num=1 | new unit num: '1' | 6.xx.xxx.xxx | 29700 | +--------+--------------------------------+------------+-------------+----------+----------------------------+----------------------------+-----------+-----------------------------------------------------------+-------------------+--------------+-------------+ 1 row in setクエリ結果において、以下のフィールドに基づいて対応するタスクレコードを見つけます：
START_TIME：タスクの開始時間。SQL_TEXT：タスクに対応するSQL文。EXTRA_INFO：変更前後のUnit Numberの数。
対応する変更レコードの
JOB_STATUS値がSUCCESSの場合、Unit Numberを増やすタスクが正常に実行されたことを意味します。ビュー
DBA_OB_TENANT_JOBSの詳細なフィールド説明については、DBA_OB_TENANT_JOBSを参照してください。テナント
mysql001の変更後のUnitを確認します。obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, UNIT_CONFIG_ID FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1006;クエリ結果は次のとおりです：
+---------+-----------+----------+------------------+---------------+-------+----------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | UNIT_CONFIG_ID | +---------+-----------+----------+------------------+---------------+-------+----------------+ | 1006 | 1006 | ACTIVE | 1003 | 1019 | zone3 | 1001 | | 1012 | 1006 | ACTIVE | 1001 | 1019 | zone1 | 1001 | | 1013 | 1006 | ACTIVE | 1002 | 1021 | zone2 | 1001 | | 1014 | 1006 | ACTIVE | 1001 | 1020 | zone1 | 1001 | | 1015 | 1006 | ACTIVE | 1003 | 1020 | zone3 | 1001 | +---------+-----------+----------+------------------+---------------+------+-----------------+ 5 rows in set
上記の例により、テナントmysql001のリソースプールpool2のUnit Numberを2から1に変更しました。変更前は、テナントの各ゾーンにおけるUnit数が2でした。変更後は、テナントのzone1とzone3のUnit数は引き続き2ですが、zon2のUnit数が1になり、テナントのスケールダウンが実現されました。