ノードの削除|V4.4.2|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

ノードの削除

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

OceanBaseクラスタからノードを削除できます。ノードの削除はノードの追加の逆操作であり、弾力的なスケーリングシナリオやデプロイメントの調整シナリオに適用されます。

弾力的なスケーリングシナリオ：クラスタ内にリソースの余裕がある場合、Unitの配置を調整したり、テナントのUNIT_NUMを減らしたりする操作でノードのリソース使用量を削減し、最終的にノードを削除してマシンをオフライン状態にすることができます。
デプロイメントの調整シナリオ：クラスタのデプロイメントアーキテクチャを調整する際、テナントのLocality属性を変更した結果、あるZone内にテナントのUnitが一切配置されなくなった場合、Stop Zone -> Delete Server -> Delete Zoneといった一連の操作を経てそのZoneをオフライン状態にすることができます。

注意点

Delete Server操作はロードバランシングに関わり、削除対象ノード上のリソースユニット（Unitと呼ばれる）は同一ゾーン内で移行されます。Unitの移行処理はUnitの自動バランシングプロセスであり、主にRoot Serviceによって制御されます。Unitの移行が成功すれば、Delete Server操作も正常に実行されます。削除対象ノード上のUnitを移行するターゲットマシンを選択したい場合は、手動でUnit移行を実行できます。

注意

ノードの削除は利用可能なリソースを減らします。同一ゾーン内の他のノードの残存リソースが削除対象ノード上のUnitを収容するには不十分な場合、Unitの移行は失敗します。そのため、ノードの削除を実行する前に、oceanbase.GV$OB_SERVERSビューを確認し、ゾーン内の各ノードのリソース使用状況を判断することを推奨します。

Unitの自動移行プロセスでは、移行タスクが移出手元ノードと移行先ノードのネットワークリソースおよびI/Oリソースを占有するため、移行トラフィックと業務トラフィックが重なり、業務トラフィックに影響を及ぼす可能性があります。業務プロセスへの影響を避けるためには：

まずStop Zone操作を実行してからDelete Server操作を実行することで、両方のトラフィックが重ならないようにできます。

Stop Zoneの関連操作については、ノードの分離を参照してください。

移行タスクの関連パラメータを調整することで、移行速度を制御することもできます。

移行タスクに関連するパラメータは以下の表のとおりです。

パラメータ名	説明
balancer_idle_time	テナントレベルの構成パラメータで、移行タスクを開始する間隔時間を制御します。デフォルト値は10秒です。[10s, +∞)の範囲で設定できます。
sys_bkgd_net_percentage	クラスタレベルの構成パラメータで、移行タスクがNIC帯域幅に占用する割合を制御します。デフォルト値は60です。[0, 100]の範囲で設定できます。

各パラメータの値を確認および変更する操作については、クラスタパラメータの変更を参照してください。

手順

rootユーザーでクラスタのsysテナントにログインします。

接続例は以下のとおりですが、データベースへの接続時には実際の環境に合わせてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
```
データベース接続の詳細な操作手順については、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。

（オプション）削除対象ノード上のUnitを手動で移行します。

注意

ノードを停止する際は、削除対象ノード上のUnitを手動で移行してからDelete Server操作を実行することを推奨します。

現在のUnit分布を確認し、移行対象のUnitのIDを取得します。

obclient [(none)]> SELECT UNIT_ID,TENANT_ID,STATUS,ZONE,SVR_IP FROM oceanbase.DBA_OB_UNITS;
+---------+-----------+--------+-------+----------------+
| UNIT_ID | TENANT_ID | STATUS | ZONE  | SVR_IP         |
+---------+-----------+--------+-------+----------------+
|       1 |         1 | ACTIVE | zone1 |   xx.xx.xx.237 |
|       2 |         1 | ACTIVE | zone2 |   xx.xx.xx.238 |
|       3 |         1 | ACTIVE | zone3 |   xx.xx.xx.218 |
|    1001 |      1002 | ACTIVE | zone3 |   xx.xx.xx.218 |
|    1002 |      1002 | ACTIVE | zone1 |   xx.xx.xx.237 |
|    1003 |      1002 | ACTIVE | zone2 |   xx.xx.xx.238 |
|    1010 |      1008 | ACTIVE | zone3 |   xx.xx.xx.218 |
|    1011 |      1008 | ACTIVE | zone2 |   xx.xx.xx.238 |
|    1012 |      1008 | ACTIVE | zone1 |   xx.xx.xx.237 |
|    1013 |      1010 | ACTIVE | zone3 |   xx.xx.xx.218 |
|    1014 |      1010 | ACTIVE | zone1 |   xx.xx.xx.237 |
|    1015 |      1010 | ACTIVE | zone2 |   xx.xx.xx.238 |
|    1016 |      NULL | ACTIVE | zone1 |   xx.xx.xx.237 |
|    1017 |      NULL | ACTIVE | zone2 |   xx.xx.xx.238 |
+---------+-----------+--------+-------+----------------+
14 rows in set

ここで：

UNIT_ID：ノード上の各UnitのIDを表します。
TENANT_ID：そのUnitが属するテナントIDを表します。値がNULLの場合、現在のUnitはどのテナントにも属していないことを意味します。
STATUS：そのUnitの現在の状態を表します：
- ACTIVE：正常な状態
- DELETING：削除中の状態
ZONE：そのUnitが属するZoneを表します。
SVR_IP：そのUnitが属するノードのIPを表します。

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

クエリ結果に基づき、以下のコマンドを実行してUnitを手動で移行します。

ステートメントは以下のとおりです：
```
obclient [(none)]> ALTER SYSTEM MIGRATE UNIT = unit_id DESTINATION = 'svr_ip:svr_port';
```
関連パラメータの説明は以下のとおりです：
- unit_id：移行対象のUnitのIDを表します。
- svr_ip：Unit移行後のノードのIPを指定します。
- svr_port：Unit移行後のノードのRPCポートを指定します。
IDが1012のUnitを同一Zone内の172.xx.xx.xxサーバーに移行する例を以下に示します：
```
obclient [(none)]> ALTER SYSTEM MIGRATE UNIT = 1012 DESTINATION = '172.xx.xx.xx:2882';
```
このコマンドは複数回実行可能です。Unitの手動移行に失敗した場合は、エラーメッセージに基づいて問題を解決した後、再度実行してください。

Unit移行の操作と説明の詳細については、Unit移行を参照してください。

以下のコマンドを実行してノードを削除します。

ステートメントは以下のとおりです：
```
obclient [(none)]> ALTER SYSTEM DELETE SERVER 'svr_ip:svr_port' [,'svr_ip:svr_port'...] [ZONE [=] 'zone_name']
```
関連パラメータの説明は以下のとおりです：
- svr_ip：削除対象ノードのIPを表します。
- svr_port：削除対象ノードのRPCポートを表します。
- zone_name：削除対象ノードが属するZoneを表します。複数のノードを削除する必要がある場合、複数のノードは同一Zone内である必要があります。
zone1からOBServerサーバーを1台削除する例を以下に示します：
```
obclient [(none)]> ALTER SYSTEM DELETE SERVER "172.xx.xx.xx:2882" zone='zone1'
```
すべての操作が終了したら、oceanbase.DBA_OB_SERVERSビューをクエリして、ノードが正常に削除されたかどうかを確認します。
```
obclient [(none)]> SELECT * FROM oceanbase.DBA_OB_SERVERS;
```
リストで該当ノードが見つからない場合、削除に成功したことを意味します。リストにまだそのノードが存在し、そのノードの状態がDELETINGの場合、そのノードはまだ削除中であることを意味します。

Unitを手動で移行せずに直接Delete Server操作を実行した場合、ノードの削除が失敗する可能性があります。ノードの削除に失敗した場合は、今後の操作を参照して処理してください。

次のステップ

Unitを手動で移行せずに直接Delete Server操作を実行した場合、Unitの均衡処理中にリソース不足が発生する可能性があります。具体的には、同ゾーン内の他のノードの残りリソースが削除対象ノード上のUnitを収容できないため、Unitの移行が失敗し、そのノードが継続的に削除状態となることです。Root Serviceマシンの/home/admin/oceanbase/log/rootservice.logファイルを確認することで、Unitの移行失敗が発生したかどうかを確認できます。Unitの移行失敗が確認された場合は、Cancel Delete Server操作を実行し、ゾーン内にノードを追加してクラスタを拡張した後、再度ノードを削除する必要があります。ゾーン内にノードを追加する操作の詳細については、ノードの追加を参照してください。

Cancel Delete Serverの具体的な操作手順は以下のとおりです：

rootユーザーでクラスタのsysテナントにログインします。

接続例は以下のとおりです。データベースへの接続時は、実際の環境に合わせてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
```
以下のステートメントを実行して、ノードの削除をキャンセルします。

ステートメントは以下のとおりです：
```
obclient [(none)]> ALTER SYSTEM CANCEL DELETE SERVER 'svr_ip:svr_port' [,'svr_ip:svr_port'...] [ZONE [=] 'zone_name']
```
関連パラメータの説明は以下のとおりです：
- svr_ip：削除をキャンセルするノードのIPアドレスを表します。
- svr_port：削除をキャンセルするノードのRPCポートを表します。デフォルトは2882です。
- zone_name：削除をキャンセルするノードが属するゾーンを表します。
例：
```
obclient [(none)]> ALTER SYSTEM CANCEL DELETE SERVER '172.xx.xx.xx:2882' zone='zone1';
```
oceanbase.DBA_OB_SERVERSビューをクエリし、ノードの削除キャンセルが成功したかどうかを確認します。
```
obclient [(none)]> SELECT * FROM oceanbase.DBA_OB_SERVERS;
```
削除をキャンセルするOBServerの状態がDELETINGからACTIVEに変更された場合、削除キャンセルが成功したことを意味します。

OceanBase

顧客事例

ノードの削除

注意点

注意

手順

注意

次のステップ

関連ドキュメント