前言
当前 Doris 版本
0.14
,一个古老的版本 …
云服务成本攀升,为降低成本,开始将一些资源使用率相当较低的云服务进行缩容,Doris 也加入了这个行列…
这一两年(2020-2022) Doris 发展很快,直观来看就是版本迭代快,从 0.xx 快速进入 1.xx 序列,也就意味着功能、性能、Bug 等都不断完善 …
Doris 提供了平滑缩容策略,支持在不影响业务的情况下,完成数据迁移以及节点剔除,但这过程中会遇到一些问题,我们一起来看看~
一、平滑缩容
1. 指令:
ALTER SYSTEM DECOMMISSION BACKEND
节点下线操作用于安全下线节点。该操作为异步操作。如果成功,节点最终会从元数据中删除。如果失败,则不会完成下线(仅管理员使用!)
语法:
ALTER SYSTEM DECOMMISSION BACKEND "host:heartbeat_port"[,"host:heartbeat_port"...];
- host 可以是主机名或者ip地址
- heartbeat_port 为该节点的心跳端口
- 节点下线操作用于安全下线节点。该操作为异步操作。如果成功,节点最终会从元数据中删除。如果失败,则不会完成下线。
- 可以手动取消节点下线操作。详见 CANCEL DECOMMISSION
下线两个节点:
ALTER SYSTEM DECOMMISSION BACKEND "host1:port", "host2:port";
2. 缩容:
在测试环境下验证,缩容一个拥有 500 tablet 的节点大概花了 1 天时间。线上同时缩容 4 个节点,预估 2 - 3 天能完成。
2-3 天后的结果:
进度缓慢,看起来就是卡住了,不能听之任之了,网上有人也遇到了类似的情况,Doris decommission be节点卡住 。
调整参数 catalog_trash_expire_second
后继续尝试,一周后:
进展相当缓慢,完全不能忍了。
二、解决
1. 寻找方案:
经过对比发现大部分表数据副本已「迁移」完成,副本迁移完成的最终效果如下:
可通过指令查看数据分布情况:
ADMIN SHOW REPLICA DISTRIBUTION FROM table_name
经过一番排查后发现,目前只剩「几张表」数据副本未迁移完成,对剩下的几张表进行风险评估,最终决定采用方案:
- 有原表:从原表重新拉取数据
- 无原表:将数据进行备份
2. 处理步骤:
1、暂停流计算、离线任务
2、删表:
truncate table table_name
or
drop table table_name
一般情况下,这些数据未完成迁移的表被删除后,由于平滑缩容仍在继续,这些所容节点会立即被踢出集群完成缩容。
3、强制缩容:
如果删表后发现未完成缩容,可采用如下命令进行强制缩容:
ALTER SYSTEM DROPP BACKEND "be_host:be_heartbeat_service_port";
4、重建表
5、初始化数据
6、重启流计算、离线任务
7、回收机器
注
:以上方式是平滑缩容未完全成功的方案(退而求其次),需合理评估风险,并在业务低峰期处理,我们用了几分钟便完成了以上操作,业务回归正常。
三、小结
“黑猫白猫,能抓耗子就是好猫”,本文提供了一种解决思路,遇到问题,多尝试、思考,总会有解决方法。
文章评论