StarRocks源码总结-BE节点退役和踢出的区别

背景

本文涉及到的命令和配置为StarRocks2.3.5版本的内容，其他版本可能有部分差异，仅供参考！
在StarRocks数据库日常使用中，可能由于服务器的硬件故障或者其他原因，BE节点需要下线，此时有两种命令可供选择，退役（decommission）和删除（drop）。
官方文档明确提出了，在任何情况下，都推荐使用退役操作而不是删除操作，但是没有一个详细的介绍这两种操作的区别，我经过阅读了部分源码针对这两种操作有了一些自己的理解，总结如下。

退役（decommission）

命令和配置

首先是退役的命令。

alter system decommission backend "ip:port";

在执行了退役但是没有退役结束后，可以取消退役。

cancel decommission backend "ip:port"

FE节点也有一个配置和退役有关：

drop_backend_after_decommission

该配置的作用为是否在退役完成后将BE节点在集群中删除，默认为true，支持动态修改。
集群中删除的意思就是show backends;中删除了，如果后续节点想恢复使用，需要再执行add操作加入集群。

执行流程

在BE节点发起退役后，FE节点的副本状态检测器会将该BE节点的所有副本（replica）均会被标记为unhealthy。
FE节点在收集到这些副本后，会将副本放进一个待修复的队列中，队列长度为FE的配置max_scheduling_tablets，默认2000，可动态修改。
在待修复队列中有数据后，FE节点会根据队列中tablet的优先级，将开始执行数据的迁移操作。
迁移操作受到3个配置限制：
max_balancing_tablets FE配置，默认200，可动态变更，为迁移任务的最大并发。
schedule_slot_num_per_path FE配置，默认为2，为单个硬盘的最大迁移任务数量。
clone_worker_count BE配置，默认为3，不可动态变更，为BE的clone任务线程数量。
由于tablet默认有3副本，因此虽然是某一台BE进行退役，但是并不是所有数据都是由该BE 流向到其他BE，有可能是有相同数据的其他BE节点执行的操作。
等待数据迁移完毕，3副本的tablet会变成4副本，等到下一次副本检测时，就会将退役节点的副本状态标记为decommission，当BE节点检测到副本被标记为了decommission后，就会将多余副本删除。
虽然创建了大量的修复任务进入到修复队列中，但是运行的优先级是可以调整的，针对重点表，可以通过执行命令提高对应表的修复优先级，命令如下。
ADMIN REPAIR TABLE table_name[ PARTITION (p1,...)];
等待BE节点的所有tablet都被均衡完成后，节点退役完成。

删除（drop）

StarRocks BE节点的drop操作和宕机操作一样，副本的健康管理器检测到数据的3副本有1个副本发生了故障，会自动创建修复任务，将数据从健康的2副本中复制1份到其他be节点中，维持3副本可用。直到所有副本均被修复，集群的状态恢复正常。

总结

退役操作相对删除操作缓和的多，退役流程会全程保证3-4副本可用，而删除操作会短时间内变成2副本，对集群有一定风险。
不论是退役操作还是删除操作，集群短时间内都要修复大量的数据，占满了修复队列，此时需要注意，如果有正常的数据修复任务，可能无法得到及时的修复。
修复任务也会短时间内占据大量的磁盘IO和网络IO，要注意其他组件的健康状态：

1. 写入端会不会由于写入变慢造成堆积。
2. 要关注压缩状态，会不会由于磁盘IO飙升造成压缩变慢，从而引发版本号溢出问题。
3. 关注查询端的响应时间。

最后

以上就是饱满路人为你收集整理的StarRocks日常总结-BE节点Decommission和DropStarRocks源码总结-BE节点退役和踢出的区别的全部内容，希望文章能够帮你解决StarRocks日常总结-BE节点Decommission和DropStarRocks源码总结-BE节点退役和踢出的区别所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。