OceanBaseクラスタからノードを削除することができます。ノードの削除はノードの追加の逆操作であり、柔軟なスケーリングシナリオやデプロイメントの調整に適しています。
柔軟なスケーリングシナリオ：クラスタ内にリソースの余裕がある場合、Unitの配置を調整したり、テナントの
UNIT_NUMを減らしたりすることでノードのリソース使用量を削減し、最終的にノードを削除してマシンをオフライン状態にすることができます。デプロイメントの調整シナリオ：クラスタのデプロイメントアーキテクチャを調整する際、テナントのローカリティ属性を変更した結果、特定のゾーン内にテナントのユニットが一切配置されなくなった場合、Stop Zone -> Delete Server -> Delete 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操作を実行した場合、ノードの削除に失敗する可能性があります。ノードの削除に失敗したことを確認したら、次のステップを参照して処理を進めてください。
次のステップ
ユニットを手動で移行せずに直接Delete Server操作を実行した場合、ユニットの均衡処理中にリソース不足が発生する可能性があります。これは、同一ゾーン内の他のノードの残りリソースが削除対象ノード上のユニットを収容するには不十分であるため、ユニットの移行に失敗し、そのノードが引き続き削除状態になることを意味します。Root Serviceマシン上の/home/admin/oceanbase/log/rootservice.logファイルを確認することで、ユニットの移行に失敗したかどうかを確認できます。ユニットの移行に失敗したことが確認された場合は、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に変更された場合、削除キャンセルが成功したことを意味します。
関連ドキュメント
その他のノード関連の運用保守操作については、以下の情報を参照してください：