导读 本文主要分享数据均衡过程中的异常问题排查流程、定位调优和常见FAQ。
全文目录:
前提概要
均衡状态检查
均衡参数调优
常见FAQ
当集群处于以下几种情况时,可参考本文进行问题排查。
BE节点之间的数据不均
单个BE节点上的多个磁盘之间的数据不均
BE节点的上线和下线进度卡死(BE的tablet数量没有变化)
--检查方式,mysql客户端登录进行查询
admin show frontend config like '%xxxx%';
--是否开启均衡,默认为false,代表开启均衡
disable_balance = false
--是否开启单个BE上的磁盘间均衡,默认为false,代表开启磁盘间均衡
disable_disk_balance = false
--是否开启colocate表的重新定位和平衡,默认为false
disable_colocate_balance = false
--是否开启副本修复和均衡调度,默认为false,代表开启
disable_tablet_scheduler = false
--当doris版本为2.0.4之后,对于单副本的数据,需要修改下方参数为true,默认为false
enable_disk_balance_for_single_replica
--修改命令
admin set frontend config("enable_disk_balance_for_single_replica"="true");
1. 均衡权重检查
查看方式有两种(例如使用fe web界面):
登录FE的8030端口对应的web界面进行查看
使用SQL语句进行查看
① web界面查看需要点击System=>cluster_balance
② SQL语句查看
show proc '/cluster_balance/cluster_load_stat/location_default/HDD'
其中Class的等级分别为LOW/MID/HIGH,当Class均为MID时,代表当前集群的BE之间和单个BE的磁盘之间数据已均衡。均衡的权重可通过参数进行调整,详细参数见参数调优小节。
2. 均衡任务执行情况检查
① 查看当前正在执行的调度
当running任务正常,但是磁盘空间不下降,通常有两个原因
均衡调度任务正常,需要清理下trash,均衡过程中的副本会被放入trash中。执行admin clean trash清理trash。
均衡调度异常,查看均衡调度的历史信息,查看是否有报错。
② 查看均衡的历史记录信息
根据Finished进行排序,看是否有大量的CANCELLED状态。如果有,可以看最左边的ErrMsg日志。
或者通过搜索Master FE的日志grep "tablet schedule\|TableSch" fe.log|grep tablet_id
当均衡任务失败时,可以根据 常见FAQ 小节进行排查。
1. 数据不够均衡
① 参数讲解
balance_load_score_threshold 默认值 0.1
如果想让数据更加的均衡,可以适当调小该参数,触发均衡调度执行。
BE节点间判断:当BE节点的load score,与平均load score的差值的绝对值不超过10%时,认为该节点是均衡的。
磁盘间判断:当使用率不超过平均使用率的0.1*2时,认为该磁盘是均衡的。
backend_load_capacity_coeficient 默认值0.8
用于计算负载得分。
Score = UsedPercent / 平均UsedPercent * CapCoeff + ReplicaNum/平均ReplicaNum * ReplCoeff
其中ReplCoeff = 1 - CapCoeff。
我们可以通过调整该参数,决定让磁盘使用率更均衡,还是让tablet数目更加均衡。
该参数越大,磁盘使用率的相差会越小,参数越小,则tablet num相差越小。当CapCoeff=1时,无法均衡空tablet。
当各BE之间均衡程度不满足要求时,可以将balance_load_score_threshold调小,backend_load_capacity_coeficient调大(建议小于1.0)
admin set frontend config ("balance_load_score_threshold" = "xx");
admin set frontend config ("backend_load_capacity_coeficient" = "xx");
2. 均衡速度慢
单个均衡任务分为这几个步骤:
全量拷贝一个新tablet-->对新tablet进行增量拷贝-->对于冗余的tablet进行删除
均衡速度慢怎么排查?
BE的IO是不是很高,可以通过iostat -x 1查看读写的IO延时是不是很高
均衡的线程是不是太少,当磁盘IO良好时,可以通过参数进行调整,加快均衡速度
-- 要克隆的线程数
be.conf storage_medium_migrate_count = 6
-- 影响副本均衡的速度。在磁盘压力不大的情况下,可以通过调整该参数来加快副本均衡
be.conf clone_worker_count = 6
1. 事务卡死导致无法均衡
均衡失败的报错,如下图所示
检查transaction面板:点击System => transaction
寻找running的事务,按照prepare time 进行正排序, 查看是不是事务prepare time时间很早,但是状态一直是prepare。符合条件的话,需要手动把对应的事务abort掉。
Abort 事务的方法
#根据事务id进行abort
curl -X PUT --location-trusted -u user:passwd -H "txn_id:18037" -H "txn_operation:abort" http://fe_host:http_port/api/{db}/{table}/stream_load2pc
#根据label进行abort
curl -X PUT --location-trusted -u user:passwd -H "label:55c8ffc9-1c40-4d51-b75e-f2265b3602ef" -H "txn_operation:abort" http://fe_host:http_port/api/{db}/{table}/stream_load2pc
2. 单个BE上磁盘之间不均衡
均衡调度任务会优先BE之间进行均衡,当BE间均衡后,再进行单个BE间磁盘的均衡。当单个BE上某个磁盘使用率很高时,可以尝试如下调整:
调整balance_load_score_threshold参数,通过第二节方法查看均衡状态,保证BE的权重均为MID,但是单个BE的磁盘之间可以进行均衡调度。
在2.1之后的版本中,会增加MaxDisk的指标,如果MaxDisk出现了LOG/HIGH的权重,
表示最大磁盘使用率相差较大,需要马上紧急迁移。当紧急迁移完毕后,再进行正常非紧急的数据迁移。
3. 磁盘被标记为坏盘
show backends检查
当对应BE节点的相关指标都为0时,表示磁盘不存在,或者被标记为bad,
通过命令 show proc "/backends/<backend id>" 可以查看该BE 的磁盘情况。
如果State=OFFLINE,代表磁盘为bad
确认be.conf中配置的路径是否异常,是不是升级或者其他操作导致对应磁盘路径不存在了
路径存在,检查BE的日志。使用grep "IO Error" be.INFO.xxxx,或者直接grep "IO Error" be.INFO*|less,通常是因为磁盘写满了,fd的数目超过了设置,目录被删除等导致
恢复磁盘可用的步骤:
1. 查看conf/be_custom.conf 里是否有broken path,如果有删除;当然这个文件不一定有(比如当时fd数超了,会连这个文件都写不进去);
2. 重启BE节点。
4. tablet被标记为冷存
在冷热分层的场景下,满足条件的tablet会被标记为冷存,这些tablet不能在同BE的不同磁盘上迁移,但可以在BE之间迁移。
5. 表的replication allocation的tag与backend 的tag不匹配
数据的均衡只会在相同的tag中的相同storage medium上进行均衡,如果表的replication allocation的tag 跟它所在backend的tag不一样,或者backend不含有该表的storage medium ,那么也是无法均衡的。