Apache DorisのBE拡張・縮小 ミニマリスト運用保守(1)
1. 環境情報
3 つの BE ノードがデプロイされており、ステータスは正常に実行していることを示しています。
ハードウェア情報
- CPU：1C
- CPU型式：ARM64
- メモリ：2GB
- ハードディスク：36GB SSD
ソフトウェア情報
- VMイメージのバージョン：CentOS-7
- Apache ドリス バージョン: 1.2.4.1
- クラスターサイズ: 1FE * 3BE
2. 収縮
2.1 DROP BACKEND 縮小
注: DROP BACKEND は BE を直接削除し、その上のデータは回復できなくなります。！！
したがって、DROP BACKEND を使用して BE ノードを削除することは強く推奨されません。このステートメントを使用すると、対応する誤操作防止プロンプトが表示されます。
-- ALTER SYSTEM DROP BACKEND "be_host:be_heartbeat_service_port"; -- 会有误操作提示
-- ALTER SYSTEM DROPP BACKEND "be01:9050"; --直接删除，慎用！
2.2 廃止バックエンドの縮小
DECOMMISSION コマンドの説明:
- このコマンドは、BE ノードを安全に削除するために使用されます。コマンドが発行された後、Doris は BE 上のデータを他の BE ノードに移行しようとし、すべてのデータが移行されると、Doris は自動的にノードを削除します。
- このコマンドは非同期操作です。実行後、 SHOW PROC '/backends'; を使用して、BE ノードの isDecommission ステータスが true であることを確認できます。ノードがオフラインになることを示します。
- コマンドは必ずしも正常に実行されるとは限りません。たとえば、残りの BE ストレージ スペースがオフライン BE 上のデータを収容するのに十分でない場合、または残りのマシンの数が最小コピー数を満たしていない場合、コマンドは完了できず、BE は常にisDecommission の状態は true です。
- DECOMMISSION の進行状況は、SHOW PROC '/backends'; TabletNum で確認できます。進行中の場合、TabletNum は減少し続けます。
- この操作は次の方法で実行できます。
CANCEL DECOMMISSION BACKEND "be_host:be_heartbeat_service_port";
注文がキャンセルされました。キャンセル後、BE 上のデータは現在の残りのデータ量を維持します。後続のドリスは負荷のバランスを再調整します
-- ALTER SYSTEM DECOMMISSION BACKEND "be_host:be_heartbeat_service_port";
ALTER SYSTEM DECOMMISSION BACKEND "be01:9050";
2.2.1 スケールダウン前
http://192.168.31.78:8030/System?path=//backends ノード情報の表示
2.2.2 縮小
スケールダウンに失敗しました。残りのマシンの数が最小コピー数(3 コピー)を満たしていないため、縮小中の BE ノードは常に isDecommission が true の状態になります。
- DECOMMISSION BACKEND をキャンセルし、3 コピーのテーブルを 2 コピーに調整します
-- 取消DECOMMISSION BACKEND
-- CANCEL DECOMMISSION BACKEND "be_host:be_heartbeat_service_port";
CANCEL DECOMMISSION BACKEND "be01:9050";
-- 3副本表调成2副本
-- 非分区部分
ALTER TABLE db.table_name SET ("default.replication_num" = "2");
ALTER TABLE db.table_name SET ("default.replication_allocation" = "tag.location.default: 2");
-- 分区部分
ALTER TABLE zbh_test.dwd_lbu_mbi_bil_income_d02 MODIFY PARTITION (逗号分隔可填写多个分区名) SET("replication_num"="2");
-- 如下图所示tablet数开始减少至2副本的量
- 縮小のためのコピー要件を満たした後、DECOMMISSION BACKEND を再実行します。
-- ALTER SYSTEM DECOMMISSION BACKEND "be_host:be_heartbeat_service_port";
ALTER SYSTEM DECOMMISSION BACKEND "be01:9050";
2.2.3 スケールダウン後
コピーは、オフラインでないノードに対して自動的にバランスがとられます。コピーのバランスがとれた後、オフラインのノードは自動的に削除されますが、プロセスは自動的に停止する必要があります。
# 需要手动停止be进程
sh bin/stop_be.sh
3. 拡張
3.1 拡張前
3.2 容量の拡張
-- 新增be节点，需要确保已经start相应的be进程
alter system add backend "192.168.31.136:9050"
-- 如下图所示新be已经加入集群并开始自动进行数据均衡了
3.3 拡張後
データが完全にバランス化されると、次の図に示すように、圧縮が完了する前の 2 つのコピーのタブレット分布とほぼ同等になります。
4. まとめ
- 容量拡張によりデータのバランスが自動的に調整されます
- スケーリングするとデータバランスが自動的に実行されますが、直接 DROP しないように注意する必要があります。DECOMMISSION に移動して stop_be.sh を実行する必要があります。
- 移行効率のリファレンス: コピー移行 ( 1.590 TB / 141 タブレット)は 16:32 に開始され、移行は 17:39 に完了し、平均は 1667235 メートル / 4020 秒 = 414 メートル/秒でした (大きなテーブルには時間がかかり、タブレットを表示できます) weiui の統計によりまだ移行中です); 移行後、ノードはオフラインになり、show PROC '/backends' にはオフライン ノードが表示されません。