FE 调参后重启失败

starrocks版本:1.19.5
集群规模:3fe+5be 其中一台fe与be混部


因为监控显示fe jvm head占用高,所以调大参数后滚动重启fe,
在操作第一台节点时,bin/stop_fe.sh 之后,发现无法启动。随后另外两台fe没有任何操作也自己down掉,查看fe日志显示如下:
fe.warn.log

fe.log

fe.out

发现日志中并无有效报错信息。
这里有个事情需要插一嘴下,就是之前出现的一些问题:在同一网段其他机器安装完一个单节点测试的sr后 ,发现一个神奇的现象就是 测试节点挂掉之后,会影响线上的服务。线上的节点也会挂掉。

而且后面线上环境出现了 3fe 没有HA的现象,就是其中一台fe down掉 另外两台也不提供服务了。 还有就是不论三个fe 启动顺序是怎样 master始终都是一台节点。从来也没有切换过。。

思考会不会也是测试集群链到了线上导致的,随后吧测试节点的fe http端口改掉,发现并没有用。

于是在社群求助 大佬推荐升级试下,

于是将1.19.5 升级为2.0.1版本
升级后分别启动3个fe 等待大概5分钟左右,3fe服务 都恢复正常 。
至此还不太确定 事故原因。 而且不确定2.0.1版本是否还会有 3fe 并不是HA的现象出现。因为是线上服务所以不敢在上面测试。

日志报错内容stop再启动的fe,和挂掉的fe的日志应该是不一样。是否可以补全一下以帮您定位。还有数据库叫starrocks,希望您可以改下描述

z这个看起来是刚重启的时候的异常

关于三个FE节点 down掉一台,另外两台也无法访问的问题:
集群中有一台fe节点与be混部 恰好这台fe为master节点。
早晨因为负载过高导致 这台混部的be与fe 挂掉。 此时在另外存活的两台fe 执行命令:
show frontends;
mater并没有主动切换。所以SQL执行异常。

ERROR 1064 (HY000): Failed to get master client.


待fe恢复后 ,SQL执行正常:

所以现在虽然部署了三个fe节点,但是现在并不是高可用状态。。

怀疑你的测试集群和生产集群是一个集群,在fe的目录下使用这个目录查看一下
java -jar lib/je-7.3.7.jar DbGroupAdmin -helperHosts {ip:edit_log_port} -groupName PALO_JOURNAL_GROUP -dumpGroup
ip:edit_log_port 换成master的ip和端口

确实。。。之前我也怀疑是搞到同一个集群了,但是我通过show frontends并没有发现 测试的节点。而且我也并没有在线上集群执行添加测试fe节点的命令,测试集群启动时也没有指定helper。 感觉应该是哪里的bug。

如图。129 这台节点是测试节点。不知道为啥会连到一起。我之前已经把129这个节点的所有fe端口都改为非默认的好像也没有解决这个问题。
线上集群:

测试节点:

使用这个命令把129这个节点从生产环境删除一下

java -jar lib/je-7.3.7.jar DbGroupAdmin -helperHosts 192.168.100.111:9010 -groupName PALO_JOURNAL_GROUP -removeMember 192.168.100.129_9010_1641525519456

1赞

现在你的生产环境在paxos协议中看到的是4个节点,4个节点的quorum是3,所以必须有3个节点存活才是可用。

master一直是111吗?能把这个的meta/bdb/je.info日志发一下吗

是的,之前master一直是111这种情况应该是从测试集群搭建起来之后出现的状况,我刚把129这个从生产环境删除了。如果后续有fe节点挂掉可以在观察一下 ,现在还不会不会切换 master。

或者有办法主动切换master吗

je.info 日志:
je.info.0 (212.2 KB)

现在应该是高可用的了,如果主挂掉会从其他2个节点选出主来。现在还不能主动切主。

我分析一下日志,看看是为什么129跑到生产环境上去了

这里还有份历史的je.info 需要的话可以看下。
je.info.1 (9.5 MB)