メインコンテンツまでスキップ
バージョン: 26.x

バックエンドの廃止

説明​

このステートメントは、クラスターからBEノードを安全に廃止するために使用されます。この操作は非同期です。

構文​

ALTER SYSTEM DECOMMISSION BACKEND "<be_identifier>" [, "<be_identifier>" ... ]

どこで:

be_identifier
  : "<be_host>:<be_heartbeat_port>"
  | "<backend_id>"

必須パラメーター​

1. <be_host>

BEノードのホスト名またはIPアドレスを指定できます。

2. <heartbeat_port>

BEノードのハートビートポートです。デフォルトは9050です。

3. <backend_id>

BEノードのIDです。

ヒント

<be_host>、<be_heartbeat_port>、<backend_id>はすべてSHOW BACKENDS文でクエリして取得できます。

アクセス制御要件​

このSQLを実行するユーザーは、少なくとも以下の権限を持つ必要があります：

PrivilegeObject注釈
NODE_PRIV

使用上の注意​

  1. このコマンドを実行した後、SHOW BACKENDS文を使用して、廃止ステータス（SystemDecommissioned列の値がtrue）と廃止の進行状況（TabletNum列の値が徐々に0まで減少）を確認できます。
  2. 通常の状況では、TabletNum列の値が0まで減少した後、このBEノードは削除されます。DorisにBEを自動的に削除させたくない場合は、FE Masterのコンフィギュレーションdrop_backend_after_decommissionをfalseに変更できます。
  3. 現在のBEが比較的大量のデータを格納している場合、DECOMMISSION操作は数時間または数日続く可能性があります。
  4. DECOMMISSION操作の進行状況が停滞した場合、具体的にはSHOW BACKENDS文のTabletNum列が特定の値で固定される場合、以下の状況が原因である可能性があります：
    • 現在のBE上のタブレットを移行するための適切な他のBEが存在しない。例えば、3レプリカのTableを持つ3ノードクラスターで、そのうちの1つのノードを廃止する場合、このノードはデータを移行する他のBEを見つけることができません（他の2つのBEはすでにそれぞれ1つのレプリカを持っています）。
    • 現在のBE上のタブレットがまだごみ箱に存在している。ごみ箱を空にしてから廃止を待つことができます。
    • 現在のBE上のタブレットが大きすぎて、単一タブレットの移行が常にタイムアウトし、このタブレットを移行できない。FE Masterのコンフィギュレーションmax_clone_task_timeout_secをより大きな値に調整できます（デフォルトは7200秒）。
    • 現在のBEのタブレット上に未完了のトランザクションが存在している。トランザクションの完了を待つか、手動でトランザクションを中止できます。
    • その他の場合、FE Masterのログでreplicas to decommissionキーワードをフィルタリングして異常なタブレットを見つけ、SHOW TABLET文を使用してこのタブレットが属するTableを見つけ、新しいTableを作成し、古いTableから新しいTableにデータを移行し、最後にDROP TABLE FORCEを使用して古いTableを削除します。

例​

  1. BEのHostとHeartbeatPortに従って、クラスターから2つのノードを安全に廃止する。

    ALTER SYSTEM DECOMMISSION BACKEND "192.168.0.1:9050", "192.168.0.2:9050";

  2. BEのIDに従って、クラスターからノードを安全に廃止する。

    ALTER SYSTEM DECOMMISSION BACKEND "10002";