该篇文章记录测试环境中StarRocks元数据恢复的操作流程。
? ? ? ? ? 元数据恢复缘由:2023年7月底基于StarRocks3.0.0集群测试物化视图及动态建表等功能,一切正常。几天后重新连接集群发现已宕机,FE拒接连接,FE 节点之间无法同步数据。
报错日志如下:
查看fe.conf ,be.conf等配置文件,发现参数已重置为初始值(原因未知),部分截图如下:
排查后,源三台服务器的元数据meta以及storage可回溯,路径分别是:/data/starrocks/fe/meta 以及 /data/starrocks/be/storage,针对上述异常,接下来开始手动恢复 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,该值越大则该节点元数据越新。返回结果如下:
注:
例如:节点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)
? ? ? 通过以上步骤,节点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
?参考文档:
总结:
? ?上述手动恢复 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 |