OceanBaseクラスタからノードを削除できます。ノードの削除はノードの追加の逆操作であり、弾力的なサイズ変更シナリオやデプロイメントの調整シナリオに適用されます。
弾力的なサイズ変更シナリオ：クラスタ内にリソースの余裕がある場合、Unitの分散を調整したり、テナントの
UNIT_NUMを減らしたりする操作でノードのリソース使用量を削減し、最終的にノードを削除してマシンをオフライン状態にできます。デプロイメントの調整シナリオ：クラスタのデプロイメントアーキテクチャを調整する際、テナントのLocality属性を調整した結果、特定のZone内にテナントのUnitが配置されなくなった場合、Stop Zone -> Delete Server -> Delete Zoneといった一連の操作を通じてそのZoneをオフライン状態にできます。
注意事項
Delete Server操作はロードバランシングに関わるため、削除対象ノード上のリソースUnit（Unitと呼ばれる）は同一Zone内で移行されます。Unitの移行動作はUnitの自動バランシングプロセスであり、主にRoot Serviceによって制御されます。Unitの移行が成功すれば、Delete Server操作も正常に実行されます。削除対象ノード上のUnitを移行するターゲットマシンを選択したい場合は、Unitの移行を手動で実行できます。
注意
ノードを削除すると利用可能なリソースが減少します。同一Zone内の他のノードの残りリソースが削除対象ノード上のUnitを収容するには不十分な場合、Unitの移行は失敗します。そのため、ノードの削除を実行する前に、oceanbase.GV$OB_SERVERSビューを確認し、Zone内の各ノードのリソース使用状況を判断することを推奨します。
Unitの自動移行プロセスでは、移行タスクが移出行ノードと移入行ノードのネットワークリソースおよびI/Oリソースを占有し、移行トラフィックと業務トラフィックが重なり合い、業務トラフィックに影響を与える可能性があります。業務プロセスへの影響を避けるために：
まずStop Zone操作を実行し、その後Delete Server操作を実行することで、両方のトラフィックが重ならないようにできます。
Stop Zoneに関する操作については、ノードの分離を参照してください。
移行タスクの関連パラメータを調整することで、移行速度を制御することもできます。
移行タスクに関連するパラメータは以下の表のとおりです。
パラメータ名説明balancer_idle_time テナントレベルのパラメータで、移行タスクを開始する間隔時間を制御できます。デフォルト値は10sで、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：削除対象ノードが属するゾーン。複数のノードを削除する場合、それらのノードはすべて同一ゾーン内に存在している必要があります。
zone1内の1台のOBServerサーバーを削除します。例：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の移行が失敗し、そのノードが継続的に削除状態となります。Unitの移行失敗については、Root Serviceマシンの /home/admin/oceanbase/log/rootservice.log を確認できます。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に変わった場合、削除キャンセルは成功したことを意味します。
関連ドキュメント
ノード関連の運用操作の詳細については、以下を参照してください：