StarRocks启动失败——修复全流程

StarRocks修复全流程

背景

技术栈

公司有个项目，主要是根据活动情况、室外温度等来动态调节场地的空调和照明的这么一个系统。其中后端技术栈使用到了java、springboot、redis、mqtt、rabbitmq、kafka、mysql、starrocks。其中starrocks和mysql差不多，都是用来存数据的，不过starrocks有一个特性叫routine load，可以自动从kafka里取数据，而不需要写代码。

事情原委

在五月份，上任实习生误把生产环境中的kafka、starrocks删除了，老板请外面的人来修复，对于容器以及里面的表单进行了重构，之后问题解决。但在一个月前（八月份），生产环境的设备故障重启了一次，需要重新把服务启动，但是发现starrocks总是启动失败。

日志如下：

StarRocks [(Blazing Fast)]> _

2025-08-13 10:48:59,840 INFO Set uid to user 0 succeeded
2025-08-13 10:48:59,866 INFO RPC interface ‘supervisor’ initialized
2025-08-13 10:48:59,866 CRIT Server ‘unix_http_server’ running without any HTTP authentication checking
2025-08-13 10:48:59,867 INFO supervisord started with pid 7
2025-08-13 10:49:00,875 INFO spawned: ‘beservice’ with pid 50258
2025-08-13 10:49:00,880 INFO spawned: ‘broker’ with pid 50259
2025-08-13 10:49:00,883 INFO spawned: ‘director’ with pid 50260
2025-08-13 10:49:00,886 INFO spawned: ‘feproxy’ with pid 50261
2025-08-13 10:49:01,148 INFO spawned: ‘feservice’ with pid 50687
2025-08-13 10:49:00+00:00 INFO checking if need to perform auto registring Backend and Broker …
2025-08-13 10:49:06,155 INFO success: beservice entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2025-08-13 10:49:06,155 INFO success: broker entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2025-08-13 10:49:06,155 INFO success: director entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2025-08-13 10:49:06,155 INFO success: feproxy entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2025-08-13 10:49:06,155 INFO success: feservice entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2025-08-13 10:49:41+00:00 INFO checking if FE service query port:9030 alive or not …
2025-08-13 10:49:41+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:43+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:45+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:47+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:49+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:51+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:53+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:55+00:00 WARN FE service query port:9030 is NOT alive yet!
2025-08-13 10:49:57+00:00 INFO FE service query port:9030 is alive!
2025-08-13 10:49:57+00:00 INFO generate my.cnf file …
2025-08-13 10:50:33+00:00 INFO check if need to add BE into FE service …
2025-08-13 10:50:33+00:00 ERROR Password error, stop retrying!
If the root user password is changed, please re-run the container with ‘-e MYSQL_PWD=<root_password>’
2025-08-13 10:50:33+00:00 ERROR will force shutdown in 15 seconds …
2025-08-13 10:50:48,668 INFO waiting for beservice, broker, director, feproxy, feservice to die
Shut down
2025-08-13 10:50:48,704 INFO exited: director (exit status 1; not expected)
2025-08-13 10:50:49,706 INFO stopped: feservice (exit status 143)
2025-08-13 10:50:49,712 INFO stopped: feproxy (exit status 0)
2025-08-13 10:50:50,713 INFO stopped: broker (terminated by SIGTERM)
2025-08-13 10:50:50,716 INFO stopped: beservice (terminated by SIGKILL)

---

进行过的尝试

1. 新建一个starrocks，查看java程序运行时能否自动建表。

   结果：没有自动建表。

2. 旧容器挂载数据卷到宿主机，启一个新容器用挂载的数据卷。

   结果：同样无法启动，错误日志和旧容器一模一样。

3. 看错误日志可能是启动密码的配置问题，启新容器挂载数据卷，并指定密码

   结果：启动失败，同样的报错。

4. 经过以上尝试，证明旧容器的数据卷有问题，尝试完全抛弃旧的容器，从零开始开一个新的starrocks，并使用前任员工给出的建表语句。

   结果：可以启动，部份表有数据。 怀疑建表语句不是最新，或后来有过修改。

偶然的发现

前提一：

新建的数据库是空的，也没有密码，甲方那边说还是要新建一个密码，故通过exec进入容器内部，mysql -h的方式设置了starrocks的登录密码，同时通过DBeaver用密码可以连接。

前提二：

​ 前一天晚上老板和同事研究下来，可能是starrocks的版本与linux系统版本不匹配导致的，生产环境的系统是Anolis OS release 8.9，是阿里云的系统，与CentOS8同源，但starrocks的镜像为starrocks/allin1-ubuntu。

​ 但经查阅后，发现starrocks是通过docker部署的，已经容器化了，与宿主机环境没有影响，同时exec进入starrocks内部可以看见当前环境就是ubuntu。即便如此，老板还是坚持要换成CentOS的starrocks （心里吐槽了一万遍，byd不懂技术还瞎指挥），没办法，谁发钱谁就是老大，只得乖乖照做。。。

​ 不过转念一想，既然原来的没报错，那我根本没必要重新搞一套，把原来的镜像重命名一下不就好了嘛😂说干就干，用创建了新的镜像，为了搞得真实一点，不让大小一样，我还往里面塞了1.5G的垃圾，乍一看跟真的一样。

​ 之后发现docker ps查看到的容器也会显示images，已经启了的还没法改，只得忍痛抛弃昨天搞了一半的重新再启动一个。正在操作之时，发现昨天加了密码的restart了之后，居然没法用DBeaver连接了，遂进入日志，发现居然和旧容器的报错一模一样！

​ 这绝对不是偶然，这时心里已经大致有概念了，立即复盘，猜测可能是后加密码的问题。相同命令再新建一个容器，配置密码，DBeaver连接，没有报错…还差了一步重启！restart之后，我想要的画面出现了——无限重启，进入日志，果然！相同的错误。

​ 至此，bug能够复现，说明马上就能解决了。问deepseek怎么解决，按照它给出的方法一步一步地搞定了，测试连接完美。总结是之前外面请的人修复出现了问题，他当时配置下来是正常可以使用的，但当重启之后bug就出现了。

问题分析

启动流程冲突

StarRocks 的容器启动脚本 (entrypoint.sh) 在初始化时会检测是否需要进行 BE/Broker 自动注册，此过程需要通过 root 账户连接 FE（Frontend）服务。

密码变更未同步

当手动修改密码后，容器重启时启动脚本仍尝试使用默认空密码连接 FE，导致认证失败（日志中的 ERROR Password error）。

解决方式

1. 复制容器内文件到宿主机

   docker cp starrocks:/data/deploy/entrypoint.sh ./entrypoint_backup.sh

2. 在宿主机编辑

   nano entrypoint_backup.sh

3. 在文件开头添加：

   export MYSQL_PWD=“Your Password”

   但是注意：Shell 脚本中的 #!/bin/bash（shebang）必须是文件的第一行，所以这一行要放在#!/bin/bash之后。

4. 回传到容器

   docker cp entrypoint_backup.sh starrocks:/data/deploy/entrypoint.sh

5. 修改权限

   docker exec starrocks chmod +x /data/deploy/entrypoint.sh

6. 重启容器

   docker restart starrocks

7. 查看日志

   docker logs -f --tail 100 starrocks

至此，问题完美解决。