StarRocks集群元数据恢复

吵吵叭火

已于 2024-01-18 22:21:11 修改

阅读量1.9k

点赞数 23

分类专栏： # StarRocks 文章标签：数据库大数据

于 2024-01-18 21:29:38 首次发布

本文链接：https://blog.csdn.net/SHWAITME/article/details/135684224

版权

StarRocks 专栏收录该内容

39 篇文章

订阅专栏

本文详细描述了在StarRocks3.0.0集群测试环境中，遇到FE节点故障后如何通过手动恢复步骤，包括找到最新元数据节点、确认角色、配置恢复选项和重新部署FE集群的过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

该篇文章记录测试环境中StarRocks元数据恢复的操作流程。

一、恢复元数据步骤

元数据恢复缘由：2023年7月底基于StarRocks3.0.0集群测试物化视图及动态建表等功能，一切正常。几天后重新连接集群发现已宕机，FE拒接连接，FE 节点之间无法同步数据。

报错日志如下：

查看fe.conf ，be.conf等配置文件，发现参数已重置为初始值（原因未知），部分截图如下：

排查后，源三台服务器的元数据meta以及storage可回溯，路径分别是：/data/starrocks/fe/meta 以及 /data/starrocks/be/storage，针对上述异常，接下来开始手动恢复 FE 服务。

第一步：找出元数据最新的FE节点

每台节点依次执行命令：java -jar /opt/StarRocks-3.0.0/fe/lib/starrocks-bdb-je-18.3.13.jar DbPrintLog -h /data/starrocks/fe/meta/bdb/ -vd 获取 lastVLSN，该值越大则该节点元数据越新。返回结果如下：

注：

不同StarRocks版本用到的starrocks-bdb-je的jar包可能不一样，视情况调整；
/data/starrocks/fe/meta/bdb/ 是源集群的dbd绝对路径

例如：节点A以为例，得到 lastVLSN的最大值是30,760,876，如截图

同理得到节点B、节点C的lastVLSN的最大值是30,763,820，30,763,931。比较A,B,C的 lastVLSN 值大小，得出C是元数据最新的节点、同时也是恢复节点。

第二步：确认恢复节点角色

进入节点C的image目录（/data/starrocks/fe/meta/image）查看role文件，获取C的role为FOLLOWER

然后，在C节点的fe.conf 中添加：metadata_failure_recovery = true，该参数官网解释如下：

启动完成后，通过MySQL连接节点C的FE，返回结果如下：

确认启动成功后，可以看到当前C的FE角色为 Master，同时可以看到源集群中的其他FE节点（节点A、节点B）。

关键步骤：之后将节点C的 fe.conf 中的 metadata_failure_recovery=true 配置项删除，或者设置为 false，如截图。然后重启C的 FE 节点（sh bin/start_fe.sh --daemon）

第三步：重新部署 FE 集群

通过以上步骤，节点C担任可用的FE，同时也是新集群的FE master 、将节点A及节点B的FE 实例从源集群的元数据中移除，即执行以下命令：

mysql> alter system drop follower "B的IP:9010";

mysql> alter system drop follower "A的IP:9010";

接着，切换至A、B节点的 /data/starrocks/fe/meta 目录下，清空源集群遗留的bdb及image信息

最后将A、B节点作为全新FE实例，重新添加到C集群中,命令如下：

mysql> alter system add follower "B的IP:9010";

mysql> alter system add follower "A的IP:9010";

并分别在A、B节点上启动FE，命令如下：

./start_fe.sh --helper C的IP:9010 --daemon

参考文档：

元数据恢复的官方文档： StarRocks | StarRocksStarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。StarRocks 既支持从各类实时和离线的数据源高效导入数据，也支持直接分析数据湖上各种格式的数据。StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端和常用 BI 工具对接。同时 StarRocks 具备水平扩展，高可用、高可靠、易运维等特性。广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。https://docs.starrocks.io/zh-cn/2.3/administration/Metadata_recovery

StarRocks集群部署文档：第1.5章：StarRocks部署--集群部署_node has no associated database object-CSDN博客文章浏览阅读7k次，点赞7次，收藏18次。StarRocks作为新一代MPP数据库，集群部署才能充分发挥其彪悍的查询性能。生产环境下我们也推荐进行集群化部署，本章内容我们就模拟生产环境下StarRocks集群部署。1集群部署注意事项在部署StarRocks生产环境前，我们需要根据业务需求设计严谨的集群架构，一般来说，我们需要注意以下几项：1.1 FE的数量及是否需要FE的高可用FE的Follower要求为奇数个，且并不建议部署太多，通常我们推荐部署1个或3个Follower。在三个Follower时，即可实现高可用（HA）。此时，._node has no associated database objecthttps://blog.csdn.net/ult_me/article/details/121716779?spm=1001.2014.3001.5502

总结：

上述手动恢复 FE 服务的流程，简而言之是：先通过当前 meta_dir 中留存的元数据启动一个新的 Leader 节点，然后逐台添加其他 FE 实例至新的集群。

此过程中，需清空除了恢复节点（本案例中的恢复节点是C）以外其他节点的元数据目录，否则可能导致元数据错乱。

二、元数据恢复后，集群情况如下：

StarRocks3.0.0
机器节点	A	B	C
部署服务	BE	BE	BE
	FE(follower)	FE(follower)	FE(leader)
		mysql-client
客户端连接地址	B的ip:9030 root/root
FE	部署目录：/opt/StarRocks-3.0.0/fe
	日志目录: /data/starrocks/fe/log
	元数据目录: /data/starrocks/fe/meta
BE	部署目录：/opt/StarRocks-3.0.0/be
	日志目录: /data/starrocks/be/log