バックエンドの廃止
説明
このステートメントは、クラスターからBEノードを安全に廃止するために使用されます。この操作は非同期です。
構文
ALTER SYSTEM DECOMMISSION BACKEND "<be_identifier>" [, "<be_identifier>" ... ]
ここで：
be_identifier
: "<be_host>:<be_heartbeat_port>"
| "<backend_id>"
必須パラメータ
1. <be_host>
BE nodeのホスト名またはIPアドレスを指定できます。
2. <heartbeat_port>
BE nodeのheartbeat port。デフォルトは9050です。
3. <backend_id>
BE nodeのIDです。
ヒント
<be_host>、<be_heartbeat_port>、および<backend_id>は、すべてSHOW BACKENDS文でクエリして取得できます。
アクセス制御要件
このSQLを実行するユーザーは、少なくとも以下の権限を持っている必要があります：
| Privilege | Object | Notes |
|---|---|---|
| NODE_PRIV |
使用上の注意
- このコマンドを実行した後、SHOW BACKENDS文を使用して、廃止ステータス（
SystemDecommissioned列の値がtrue）と廃止の進行状況（TabletNum列の値が徐々に0まで下がる）を確認できます。 - 通常の状況では、
TabletNum列の値が0まで下がった後、このBE nodeが削除されます。DorisにBEを自動的に削除させたくない場合は、FE Masterの設定drop_backend_after_decommissionをfalseに変更できます。 - 現在のBEが比較的大量のデータを保存している場合、DECOMMISSION操作は数時間または数日間続く可能性があります。
- DECOMMISSION操作の進行状況が停滞する場合、具体的にはSHOW BACKENDS文の
TabletNum列が特定の値で固定されている場合、以下の状況が原因である可能性があります：- 現在のBE上のtabletを移行するのに適した他のBEが存在しない。例えば、3つのreplicaを持つテーブルがある3ノードクラスターで、そのうち1つのnodeを廃止する場合、このnodeはデータを移行する他のBEを見つけることができません（他の2つのBEはすでにそれぞれ1つのreplicaを持っているため）。
- 現在のBE上のtabletがまだRecycle Binにある。recycle binを空にしてから、廃止を待つことができます。
- 現在のBE上のtabletが大きすぎるため、単一tabletの移行が常にタイムアウトし、このtabletを移行できない。FE Masterの設定
max_clone_task_timeout_secをより大きな値に調整できます（デフォルトは7200秒）。 - 現在のBEのtablet上に未完了のトランザクションがある。トランザクションの完了を待つか、手動でトランザクションを中止できます。
- その他の場合は、FE Masterのログでキーワード
replicas to decommissionをフィルタリングして異常なtabletを見つけ、SHOW TABLET文を使用してこのtabletが属するテーブルを見つけ、新しいテーブルを作成し、古いテーブルから新しいテーブルにデータを移行し、最後にDROP TABLE FORCEを使用して古いテーブルを削除します。
例
-
BEのHostとHeartbeatPortに従って、クラスターから2つのnodeを安全に廃止する。
ALTER SYSTEM DECOMMISSION BACKEND "192.168.0.1:9050", "192.168.0.2:9050"; -
BEのIDに従って、クラスターからノードを安全に廃止する。
ALTER SYSTEM DECOMMISSION BACKEND "10002";
