本文介绍如何恢复 StarRocks 中的元数据。
当 StarRocks 集群中的 FE 集群出现以下问题时，您可以通过下述方式手动恢复 FE 服务：
- Berkeley DB Java Edition（BDBJE）无法启动。
- FE 节点之间无法同步数据。
- 无法向 FE 节点中写入元数据。
- FE 集群缺少 Leader 节点。
注意
- 请谨慎操作元数据。错误的操作可能导致集群数据不可逆丢失。如非集群不可用或 BDBJE 无法选主的情况，请不要参考此文档操作。
- 下述方法无法解决根本问题，仅作为尽快恢复集群运行应急操作。如需彻底修复问题，请联系官方人员协助。
手动恢复 FE 的原理为先通过当前 meta_dir 中留存的元数据启动一个新的 Master 节点，然后逐台添加其他 FE 节点。
请严格按照如下步骤操作。
您需要停止所有 FE 进程以及一切业务访问。请保证在恢复元数据期间，系统不会因为外部访问而发生其他不可预期的问题。
您需要先备份所有 FE 节点的元数据路径。该路径存储在 /fe/conf/fe.conf 中的 meta_dir 配置项下。
meta_dir = /home/disk1/sr/StarRocks-1.19.0/fe-3365df09-14bc-44a5-aabc-ccfaa5824d52/meta
元数据文件夹结构如下：
通常情况下，FE Leader 节点的元数据为最新。
为确保获取元数据最新的节点，您需要切换到各 FE 节点安装目录下，执行以下操作获取 lastVLSN，该值越大则该节点元数据越新。
java -jar lib/je-7.3.7.jar DbPrintLog -h meta/bdb/ -vd 查询结果如下所示：
您需要比较各个 FE 节点的 lastVLSN 值大小，该值最大的节点为元数据最新的节点。
进入元数据最新的节点的 image 目录查看 role 文件，确认当前节点的角色。
以下示例中路径为 /xxx/StarRocks-xxx/fe-xxx/meta/image。
注意：确认恢复节点角色后，您需要基于当前 FE 节点进行恢复。我们建议您优先选择 FOLLOWER 节点进行恢复。
如果恢复的节点的 role 为 FOLLOWER，请参考基于 FOLLOWER 节点恢复，如果恢复的节点的role为 OBSERVER，请参考基于 OBSERVER 节点恢复。
-
在当前节点的 fe.conf 中添加以下配置。
metadata_failure_recovery = true说明：
metadata_failure_recovery=true的含义为，清空 BDBJE 中其他 FE 节点的元数据，只保留待恢复的 FE 节点的元数据。如此，该 FE 节点将不会连接其他 FE 节点，而作为一个独立的 FE 节点启动。 注意：该参数只有在恢复启动时才需要设置为true。恢复完成后，请务必将其设置为false(后面有步骤说明)。否则再次重启后，BDBJE 中的元数据将会被再次被清空，导致其他 FE 节点无法正常工作。 -
启动当前 FE 节点。
sh bin/start_fe.sh --daemon
正常情况下，当前 FE 节点会以 MASTER 的角色启动。您可以在当前节点的 fe.log 中查询到
transfer from XXXX to MASTER的日志条目。 -
启动完成后，通过 MySQL 连接至当前 FE节点，执行查询导入操作，检查集群是否能够正常访问。如果无法正常防伪，您需要查看 FE 节点的启动日志，排查问题后重新启动 FE 节点。
-
确认启动成功后，检查当前 FE 节点角色。
show frontends;
您可以看到当前 FE 角色为
Master，以及之前集群所添加的所有 FE 节点。 -
【重要】将当前节点 fe.conf 中的
metadata_failure_recovery=true配置项删除，或者设置为false，然后重启当前 FE 节点。
-
将当前节点的 /image/ROLE 文件中
role=OBSERVER改为role=FOLLOWER。 -
在当前节点的 fe.conf 中添加以下配置。
metadata_failure_recovery = true说明：
metadata_failure_recovery=true的含义为，清空 BDBJE 中其他 FE 节点的元数据，只保留待恢复的 FE 节点的元数据。如此，该 FE 节点将不会连接其他 FE 节点，而作为一个独立的 FE 节点启动。 注意：该参数只有在恢复启动时才需要设置为true。恢复完成后，请务必将其设置为false(后面有步骤说明)。否则再次重启后，BDBJE 中的元数据将会被再次被清空，导致其他 FE 节点无法正常工作。 -
启动当前 FE 节点。
sh bin/start_fe.sh --daemon
正常情况下，当前 FE 节点会以 MASTER 的角色启动。您可以在当前节点的 fe.log 中查询到
transfer from XXXX to MASTER的日志条目。 -
启动完成后，通过 MySQL 连接至当前 FE节点，执行查询导入操作，检查集群是否能够正常访问。如果无法正常防伪，您需要查看 FE 节点的启动日志，排查问题后重新启动 FE 节点。
-
确认启动成功后，检查当前 FE 节点角色。
show frontends;
由于当前使用 OBSERVER 节点恢复，以上命令的返回中您可以看到当前 FE 角色为 OBSERVER，但是
IsMaster显示为true。 -
将当前节点的 fe.conf 中
metadata_failure_recovery=true注释掉。注意 请不要重启该节点，以防止这个节点在加入集群的时候报错。
-
DROP 当前 OBSERVER 节点以外的所有 FE 节点。
ALTER SYSTEM DROP BACKEND "host:heartbeat_service_port"[, "host:heartbeat_service_port", ...];
-
添加一个新的 FOLLOWER FE，假设在 hostA 上。
ALTER SYSTEM ADD FOLLOWER "hostA:edit_log_port"; -
在 hostA 上启动一个全新的 FE，并通过
--helper的方式加入集群。bin/start_fe.sh --helper "fe_host:edit_log_port" --daemon
-
启动成功后，检查当前 FE 节点角色。
show frontends;
在返回结果中，你可以观察到两个 FE 节点，其中一个是之前的 OBSERVER，另一个是新添加的 FOLLOWER，且此时 OBSERVER 为 Leader 节点。
-
确认新的 FOLLOWER 是否可以正常工作。观察如图所示的 ID 是否同步完成即可了解新的 FOLLOWER 是否正常工作。
-
确认当前新的 FOLLOWER 可以正常工作之后，跳转至第四步骤，用这个新的 FOLLOWER 的元数据，重新执行基于 FOLLOWER 节点恢复操作。以上步骤目的即为人为地制造出一个 FOLLOWER 节点的元数据，然后用该元数据重新开始故障恢复，从而避免了从 OBSERVER 恢复元数据导致的不一致的问题。
在得到了一个存活的 FOLLOWER 角色的 MASTER 后，您需要将之前的其他的 FE 从元数据删除。
ALTER SYSTEM DROP FOLLOWER/OBSERVER;然后通过加入全新 FE 的方式重新添加各 FE 节点。
bin/start_fe.sh --helper "fe_host:edit_log_port" --daemon如果对应 FE 启动失败，您需要检查当前 Leader 节点的 /fe/meta/bdb 文件夹大小。如果该文件夹过大，即超过 fe.conf 中 jvm 设置的一半，则您需要增大该设置项后重新启动。
如果以上操作正常，则元数据恢复完毕。