元数据恢复
本文档描述了当 FE 节点遇到不同异常时,如何在 StarRocks 集群中恢复元数据。
通常,您可能需要在以下情况下进行元数据恢复:
检查您遇到的问题,按照相应部分提供的解决方案,并执行任何建议的操作。
FE 无法重启
如果元数据损坏或与回滚后的集群不兼容,FE 节点可能无法重启。
回滚后元数据不兼容
当您降级 StarRocks 集群时,如果元数据与降级前的元数据不兼容,FE 可能会无法重启。
如果您在降级集群时遇到以下异常,您可以识别出此问题
UNKNOWN Operation Type xxx
您可以按照以下步骤恢复元数据并启动 FE
-
停止所有 FE 节点。
-
备份所有 FE 节点的元数据目录
meta_dir
。 -
将配置
metadata_ignore_unknown_operation_type = true
添加到所有 FE 节点的配置文件 fe.conf 中。 -
启动所有 FE 节点,并检查您的数据和元数据是否完整。
-
如果您的数据和元数据都完整,请执行以下语句来为您的元数据创建镜像文件
ALTER SYSTEM CREATE IMAGE;
-
在新的镜像文件传输到所有 FE 节点的目录 meta/image 后,您可以从所有 FE 配置文件中删除配置
metadata_ignore_unknown_operation_type= true
并重启 FE 节点。
元数据损坏
BDBJE 元数据和 StarRocks 元数据的损坏都会导致重启失败。
BDBJE 元数据损坏
VLSN Bug
您可以根据以下错误消息识别 VLSN Bug
recoveryTracker should overlap or follow on disk last VLSN of 6,684,650 recoveryFirst= 6,684,652 UNEXPECTED_STATE_FATAL: Unexpected internal state, unable to continue. Environment is invalid and must be closed.
您可以按照以下步骤解决此问题
-
清除抛出此异常的 FE 节点的元数据目录
meta_dir
。 -
使用 Leader FE 节点作为帮助程序重启 FE 节点。
# Replace <leader_ip> with the IP address (priority_networks)
# of the Leader FE node, and replace <leader_edit_log_port> (Default: 9010) with
# the Leader FE node's edit_log_port.
./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon
- 此 Bug 已在 StarRocks v3.1 中修复。您可以通过将集群升级到 v3.1 或更高版本来避免此问题。
- 如果超过一半的 FE 节点遇到此问题,则此解决方案不适用。您必须按照最后的措施中提供的说明来解决此问题。
RollbackException
您可以根据以下错误消息识别此问题
must rollback 1 total commits(1 of which were durable) to the earliest point indicated by transaction id=-14752149 time=2022-01-12 14:36:28.21 vlsn=28,069,415 lsn=0x1174/0x16e durable=false in order to rejoin the replication group. All existing ReplicatedEnvironment handles must be closed and reinstantiated. Log files were truncated to file 0x4467, offset 0x269, vlsn 28,069,413 HARD_RECOVERY: Rolled back past transaction commit or abort. Must run recovery by re-opening Environment handles Environment is invalid and must be closed.
当 Leader FE 节点写入 BDBJE 元数据但无法在挂起之前将其同步到 Follower FE 节点时,会发生此问题。重启后,原始 Leader 变为 Follower,从而损坏元数据。
要解决此问题,您只需再次重启此节点即可清除脏元数据。
ReplicaWriteException
您可以根据 FE 日志 fe.log 中的关键字 removeReplicaDb
识别此问题。
Caused by: com.sleepycat.je.rep.ReplicaWriteException: (JE 18.3.16) Problem closing transaction 25000090. The current state is:REPLICA. The node transitioned to this state at:Fri Feb 23 01:31:00 UTC 2024 Problem seen replaying entry NameLN_TX/14 vlsn=1,902,818,939 isReplicated="1" txn=-953505106 dbop=REMOVE Originally thrown by HA thread: REPLICA 10.233.132.23_9010_1684154162022(6)
at com.sleepycat.je.rep.txn.ReadonlyTxn.disallowReplicaWrite(ReadonlyTxn.java:114) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.DbTree.checkReplicaWrite(DbTree.java:880) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.DbTree.doCreateDb(DbTree.java:579) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.DbTree.createInternalDb(DbTree.java:507) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.cleaner.ExtinctionScanner.openDb(ExtinctionScanner.java:357) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.cleaner.ExtinctionScanner.prepareForDbExtinction(ExtinctionScanner.java:1703) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.DbTree.doRemoveDb(DbTree.java:1208) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.DbTree.removeReplicaDb(DbTree.java:1261) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replay.applyNameLN(Replay.java:996) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replay.replayEntry(Replay.java:722) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replica$ReplayThread.run(Replica.java:1225) ~[starrocks-bdb-je-18.3.16.jar:?]
当失败的 FE 节点 (v18.3.*) 的 BDBJE 版本与 Leader FE 节点 (v7.3.7) 的版本不匹配时,会发生此问题。
您可以按照以下步骤解决此问题
-
删除失败的 Follower 或 Observer 节点。
-- To drop a Follower node, replace <follower_host> with the IP address (priority_networks)
-- of the Follower node, and replace <follower_edit_log_port> (Default: 9010) with
-- the Follower node's edit_log_port.
ALTER SYSTEM DROP FOLLOWER "<follower_host>:<follower_edit_log_port>";
-- To drop an Observer node, replace <observer_host> with the IP address (priority_networks)
-- of the Observer node, and replace <observer_edit_log_port> (Default: 9010) with
-- the Observer node's edit_log_port.
ALTER SYSTEM DROP OBSERVER "<observer_host>:<observer_edit_log_port>"; -
将失败的节点添加回集群。
-- Add the Follower node:
ALTER SYSTEM ADD FOLLOWER "<follower_host>:<follower_edit_log_port>";
-- Add the Observer node:
ALTER SYSTEM ADD OBSERVER "<observer_host>:<observer_edit_log_port>"; -
清除失败节点的元数据目录
meta_dir
。 -
使用 Leader FE 节点作为帮助程序重启失败的节点。
# Replace <leader_ip> with the IP address (priority_networks)
# of the Leader FE node, and replace <leader_edit_log_port> (Default: 9010) with
# the Leader FE node's edit_log_port.
./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon -
在失败的节点恢复到健康状态后,您需要按照 Follower 优先,然后是 Leader 的顺序,将集群中的 BDBJE 包升级到 starrocks-bdb-je-18.3.16.jar (或将您的 StarRocks 集群升级到 v3.0 或更高版本)。
InsufficientLogException
您可以根据以下错误消息识别此问题
xxx INSUFFICIENT_LOG: Log files at this node are obsolete. Environment is invalid and must be closed.
当 Follower 节点需要完全元数据同步时,会发生此问题。当发生以下情况之一时,可能会发生此问题
- Follower 节点上的元数据滞后于 Leader 节点的元数据,Leader 节点已在自身内部完成了元数据的 CheckPoint。Follower 节点无法对其元数据执行增量更新,因此需要完全元数据同步。
- 原始 Leader 节点写入并检查其元数据,但在挂起之前无法将其同步到 Follower FE 节点。重启后,它变为 Follower 节点。由于脏元数据已检查,Follower 节点无法对其元数据执行增量删除,因此需要完全元数据同步。
请注意,当向集群添加新的 Follower 节点时,将抛出此异常。在这种情况下,您无需执行任何操作。如果现有 Follower 节点或 Leader 节点抛出此异常,您只需重启该节点即可。
HANDSHAKE_ERROR: 节点之间握手期间出错
您可以根据以下错误消息识别此问题
2023-11-13 21:51:55,271 WARN (replayer|82) [BDBJournalCursor.wrapDatabaseException():97] failed to get DB names for 1 times!Got EnvironmentFailureExce
com.sleepycat.je.EnvironmentFailureException: (JE 18.3.16) Environment must be closed, caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 18.3.16) 10.26.5.115_9010_1697071897979(1):/data1/meta/bdb A replica with the name: 10.26.5.115_9010_1697071897979(1) is already active with the Feeder:null HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed.
at com.sleepycat.je.EnvironmentFailureException.wrapSelf(EnvironmentFailureException.java:230) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(EnvironmentImpl.java:1835) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.dbi.EnvironmentImpl.checkOpen(EnvironmentImpl.java:1844) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.Environment.checkOpen(Environment.java:2697) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.Environment.getDatabaseNames(Environment.java:2455) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.starrocks.journal.bdbje.BDBEnvironment.getDatabaseNamesWithPrefix(BDBEnvironment.java:478) ~[starrocks-fe.jar:?]
at com.starrocks.journal.bdbje.BDBJournalCursor.refresh(BDBJournalCursor.java:177) ~[starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr$5.runOneCycle(GlobalStateMgr.java:2148) ~[starrocks-fe.jar:?]
at com.starrocks.common.util.Daemon.run(Daemon.java:115) ~[starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr$5.run(GlobalStateMgr.java:2216) ~[starrocks-fe.jar:?]
Caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 18.3.16) 10.26.5.115_9010_1697071897979(1):/data1/meta/bdb A replica with the name: 10.26.5.115_9010_1697071897979(1) is already active with the Feeder:null HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed. Originally thrown by HA thread: UNKNOWN 10.26.5.115_9010_1697071897979(1) Originally thrown by HA thread: UNKNOWN 10.26.5.115_9010_1697071897979(1)
at com.sleepycat.je.rep.stream.ReplicaFeederHandshake.negotiateProtocol(ReplicaFeederHandshake.java:198) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.stream.ReplicaFeederHandshake.execute(ReplicaFeederHandshake.java:250) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replica.initReplicaLoop(Replica.java:709) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoopInternal(Replica.java:485) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoop(Replica.java:412) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.RepNode.run(RepNode.java:1869) ~[starrocks-bdb-je-18.3.16.jar:?]
当原始 Leader 节点挂起并再次变为活动状态,而幸存的 Follower 节点尝试选举新的 Leader 节点时,会发生此问题。Follower 节点将尝试与原始 Leader 节点建立新的连接。但是,Leader 节点将拒绝连接请求,因为旧的连接仍然存在。一旦请求被拒绝,Follower 节点会将环境设置为无效并抛出此异常。
要解决此问题,您可以增加 JVM 堆大小或使用 G1 GC 算法。
DatabaseNotFoundException
您可以根据以下错误消息识别此问题
2024-01-05 12:47:21,087 INFO (main|1) [BDBEnvironment.ensureHelperInLocal():340] skip check local environment because helper node and local node are identical.
2024-01-05 12:47:21,339 ERROR (MASTER 172.17.0.1_9112_1704430041062(-1)|1) [StarRocksFE.start():186] StarRocksFE start failed
com.sleepycat.je.DatabaseNotFoundException: (JE 18.3.16) _jeRepGroupDB
at com.sleepycat.je.rep.impl.RepImpl.openGroupDb(RepImpl.java:1974) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.RepImpl.getGroupDb(RepImpl.java:1912) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.RepGroupDB.reinitFirstNode(RepGroupDB.java:1439) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.RepNode.reinitSelfElect(RepNode.java:1686) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.RepNode.startup(RepNode.java:874) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.node.RepNode.joinGroup(RepNode.java:2153) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.impl.RepImpl.joinGroup(RepImpl.java:618) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.ReplicatedEnvironment.joinGroup(ReplicatedEnvironment.java:558) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:619) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:464) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:538) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.util.DbResetRepGroup.reset(DbResetRepGroup.java:262) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.starrocks.journal.bdbje.BDBEnvironment.initConfigs(BDBEnvironment.java:188) ~[starrocks-fe.jar:?]
at com.starrocks.journal.bdbje.BDBEnvironment.setup(BDBEnvironment.java:174) ~[starrocks-fe.jar:?]
at com.starrocks.journal.bdbje.BDBEnvironment.initBDBEnvironment(BDBEnvironment.java:153) ~[starrocks-fe.jar:?]
at com.starrocks.journal.JournalFactory.create(JournalFactory.java:31) ~[starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr.initJournal(GlobalStateMgr.java:1201) ~[starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr.initialize(GlobalStateMgr.java:1150) ~[starrocks-fe.jar:?]
at com.starrocks.StarRocksFE.start(StarRocksFE.java:129) ~[starrocks-fe.jar:?]
at com.starrocks.StarRocksFE.main(StarRocksFE.java:83) ~[starrocks-fe.jar:?]
当您在 FE 配置文件 fe.conf 中添加配置 metadata_failure_recovery = true
时,会发生此问题。
要解决此问题,您需要删除配置并重启节点。
StarRocks 元数据损坏
您可以根据以下错误消息之一识别 StarRocks 元数据损坏问题
failed to load journal type xxx
或
catch exception when replaying
在按照下面提供的解决方案恢复元数据之前,强烈建议您向 StarRocks 社区的技术专家寻求帮助,因为此解决方案可能会导致数据丢失。
您可以按照以下步骤解决此问题
忽略错误 Journal ID (首选)
-
关闭所有 FE 节点。
-
备份所有 FE 节点的元数据目录。
-
在日志中找到错误的 Journal ID。以下日志中的
xxx
表示错误的 Journal ID。got interrupt exception or inconsistent exception when replay journal xxx, will exit
-
将以下配置添加到所有 fe.conf 文件并启动 FE 节点。
metadata_journal_skip_bad_journal_ids=xxx
-
如果启动仍然失败,请通过步骤 3 识别新的失败 Journal ID,将其添加到 fe.conf,然后在之前的配置不变的情况下重启节点。
metadata_journal_skip_bad_journal_ids=xxx,yyy
-
如果在上述步骤之后系统仍然无法启动,或者存在太多失败的 Journal ID,请继续执行恢复模式。
恢复模式
-
停止所有 FE 节点。
-
备份所有 FE 节点的元数据目录
meta_dir
。 -
将配置
metadata_enable_recovery_mode = true
添加到所有 FE 节点的配置文件 fe.conf 中。请注意,在此模式下禁止加载数据。 -
启动所有 FE 节点,并查询集群中的表以检查您的数据是否完整。
如果在查询这些表时返回以下错误,您必须等到元数据恢复完成
ERROR 1064 (HY000): capture_consistent_versions error: version already been compacted.
您可以从 Leader FE 节点执行以下语句以查看元数据恢复的进度
SHOW PROC '/meta_recovery';
此语句将显示恢复失败的分区。您可以按照返回的建议恢复分区。如果没有返回任何内容,则表示恢复成功。
-
如果您的数据和元数据都完整,请执行以下语句来为您的元数据创建镜像文件
ALTER SYSTEM CREATE IMAGE;
-
在新的镜像文件传输到所有 FE 节点的目录 meta/image 后,您可以从所有 FE 配置文件中删除配置
metadata_enable_recovery_mode = true
并重启 FE 节点。
FE 无法提供服务
当 Follower FE 节点无法执行 Leader 选举时,FE 将无法提供服务。发生此问题时,您可能会发现以下日志记录重复出现
wait globalStateMgr to be ready. FE type: INIT. is ready: false
多种异常可能会导致此问题。强烈建议您按照以下部分逐步排除问题。应用不适当的解决方案会使问题恶化,并可能导致数据丢失。
1. 大多数 Follower 节点未运行
如果大多数 Follower 节点未运行,则 FE 组将不提供服务。这里,“大多数”表示 1 + (Follower 节点数/2)
。请注意,Leader FE 节点本身是一个 Follower,但 Observer 节点不是 Follower。
-
您可以从 fe/meta/image/ROLE 文件中识别每个 FE 节点的作用
cat fe/meta/image/ROLE
#Fri Jan 19 20:03:14 CST 2024
role=FOLLOWER
hostType=IP
name=172.26.92.154_9312_1705568349984 -
您可以从 BDBJE 日志中查看 Follower 节点的总数
grep "Current group size" fe/meta/bdb/je.info.0
# The example output indicates there are three Follower nodes in the cluster.
2024-01-24 08:21:44.754 UTC INFO [172.26.92.139_29917_1698226672727] Current group size: 3
要解决此问题,您需要启动集群中的所有 Follower 节点。如果它们无法重启,请参考最后的措施。
2. 节点 IP 已更改
如果未配置节点的 priority_networks
,则 FE 节点将在重启后随机选择可用的 IP 地址。如果 BDBJE 元数据中记录的 IP 地址与用于启动节点的 IP 地址不同,则 FE 将不提供服务。
-
您可以从 fe/meta/image/ROLE 文件中查看 BDBJE 元数据中记录的 IP 地址
cat fe/meta/image/ROLE
#Fri Jan 19 20:03:14 CST 2024
role=FOLLOWER
hostType=IP
name=172.26.92.154_9312_1705568349984第一个下划线之前的
172.26.92.154
值是 BDBJE 元数据中记录的 IP 地址。 -
您可以从 FE 日志中查看用于启动节点的 IP 地址
grep "IP:" fe/log/fe.log
2024-02-06 14:33:58,211 INFO (main|1) [FrontendOptions.initAddrUseIp():249] Use IP init local addr, IP: /172.17.0.1
2024-02-06 14:34:27,689 INFO (main|1) [FrontendOptions.initAddrUseIp():249] Use IP init local addr, IP: /172.17.0.1
要解决此问题,您需要在 FE 配置文件 fe.conf 中将节点的 priority_networks
设置为 fe/meta/image/ROLE 中记录的 IP 地址,并重启节点。
3. 节点之间的系统时钟未同步
您可以根据来自 fe.out、fe.log 或 fe/meta//bdb/je.info.0 的以下错误消息识别此问题
com.sleepycat.je.EnvironmentFailureException: (JE 7.3.7) Environment must be closed, caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 7.3.7) 172.26.92.139_29917_1631006307557(2180):xxx Clock delta: 11020 ms. between Feeder: 172.26.92.154_29917_1641969377236 and this Replica exceeds max permissible delta: 5000 ms. HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed. fetchRoot of 0x1278/0x1fcbb8 state=0 expires=never
您必须同步所有节点之间的系统时钟。
4. 可用磁盘空间不足
在您将 StarRocks 升级到 v3.0 或更高版本,或者将 BDBJE 升级到 v18 或更高版本后,当存储 meta_dir
的磁盘的可用空间小于 5 GB 时,节点可能无法重启。
您可以从目录 fe/lib 下的 .jar 包中查看 BDBJE 版本。
要解决此问题,您可以扩展磁盘,或者为 FE 元数据分配一个具有更大容量的专用磁盘。
5. edit_log_port
已更改
如果 BDBJE 元数据中记录的 edit_log_port
与 fe.conf 中配置的 edit_log_port
不同,则 FE 将不提供服务。
您可以从 fe/meta/image/ROLE 文件中查看 BDBJE 元数据中记录的 edit_log_port
cat fe/meta/image/ROLE
#Fri Jan 19 20:03:14 CST 2024
role=FOLLOWER
hostType=IP
name=172.26.92.154_9312_1705568349984
第二个下划线之前的 9312
值是 BDBJE 元数据中记录的 edit_log_port
。
要解决此问题,您需要在 FE 配置文件 fe.conf 中将节点的 edit_log_port
设置为 fe/meta/image/ROLE 中记录的 edit_log_port
,并重启节点。
6. JVM 堆大小不足
您可以使用 jstat
命令查看 JVM 内存使用情况
jstat -gcutil pid 1000 1000
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 100.00 27.78 95.45 97.77 94.45 24 0.226 1 0.065 0.291
0.00 100.00 44.44 95.45 97.77 94.45 24 0.226 1 0.065 0.291
0.00 100.00 55.56 95.45 97.77 94.45 24 0.226 1 0.065 0.291
0.00 100.00 72.22 95.45 97.77 94.45 24 0.226 1 0.065 0.291
0.00 100.00 88.89 95.45 97.77 94.45 24 0.226 1 0.065 0.291
0.00 100.00 5.26 98.88 97.80 94.45 25 0.231 1 0.065 0.297
0.00 100.00 21.05 98.88 97.80 94.45 25 0.231 1 0.065 0.297
0.00 100.00 31.58 98.88 97.80 94.45 25 0.231 1 0.065 0.297
0.00 100.00 47.37 98.88 97.80 94.45 25 0.231 1 0.065 0.297
0.00 100.00 63.16 98.88 97.80 94.45 25 0.231 1 0.065 0.297
0.00 100.00 73.68 98.88 97.80 94.45 25 0.231 1 0.065 0.297
如果字段 O
中显示的百分比保持较高水平,则表示 JVM 堆大小不足。
要解决此问题,您必须增加 JVM 堆大小。
7. Latch 超时。com.sleepycat.je.log.LogbufferPool_FullLatch
您可以根据以下错误消息识别此问题
Environment invalid because of previous exception: xxx Latch timeout. com.sleepycat.je.log.LogbufferPool_FullLatch xxx'
at com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:459)
at com.sleepycat.je.latch.LatchSupport.handleTimeout(LatchSupport.java:211)
at com.sleepycat.je.latch.LatchWithStatsImpl.acquireExclusive(LatchWithStatsImpl.java:87)
at com.sleepycat.je.log.LogBufferPool.bumpCurrent(LogBufferPool.java:527)
at com.sleepycat.je.log.LogManager.flushInternal(LogManager.java:1373)
at com.sleepycat.je.log.LogManager.flushNoSync(LogManager.java:1337)
at com.sleepycat.je.log.LogFlusher$FlushTask.run(LogFlusher.java:232)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
当 FE 节点的本地磁盘压力过大时,会发生此问题。
要解决此问题,您可以为 FE 元数据分配一个专用磁盘,或者用高性能磁盘替换现有磁盘。
8. InsufficientReplicasException
您可以根据以下错误消息识别此问题
com.sleepycat.je.rep.InsufficientReplicasException: (JE 7.3.7) Commit policy: SIMPLE_MAJORITY required 1 replica. But none were active with this master.
当 Leader FE 节点或 Follower FE 节点使用过多的内存资源时,会导致 Full GC,从而发生此问题。
要解决此问题,您可以增加 JVM 堆大小或使用 G1 GC 算法。
9. UnknownMasterException
您可以根据以下错误消息识别此问题
com.sleepycat.je.rep.UnknownMasterException: (JE 18.3.16) Could not determine master from helpers at:[/xxx.xxx.xxx.xxx:9010, /xxx.xxx.xxx.xxx:9010]
at com.sleepycat.je.rep.elections.Learner.findMaster(Learner.java:443) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getMasterSocket(ReplicationGroupAdmin.java:186) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.util.ReplicationGroupAdmin.doMessageExchange(ReplicationGroupAdmin.java:607) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getGroup(ReplicationGroupAdmin.java:406) ~[starrocks-bdb-je-18.3.16.jar:?]
at com.starrocks.ha.BDBHA.getElectableNodes(BDBHA.java:178) ~[starrocks-fe.jar:?]
at com.starrocks.common.proc.FrontendsProcNode.getFrontendsInfo(FrontendsProcNode.java:96) ~[starrocks-fe.jar:?]
at com.starrocks.common.proc.FrontendsProcNode.fetchResult(FrontendsProcNode.java:80) ~[starrocks-fe.jar:?]
at com.starrocks.sql.ast.ShowProcStmt.getMetaData(ShowProcStmt.java:74) ~[starrocks-fe.jar:?]
at com.starrocks.qe.ShowExecutor.handleShowProc(ShowExecutor.java:872) ~[starrocks-fe.jar:?]
at com.starrocks.qe.ShowExecutor.execute(ShowExecutor.java:286) ~[starrocks-fe.jar:?]
at com.starrocks.qe.StmtExecutor.handleShow(StmtExecutor.java:1574) ~[starrocks-fe.jar:?]
at com.starrocks.qe.StmtExecutor.execute(StmtExecutor.java:688) ~[starrocks-fe.jar:?]
at com.starrocks.qe.ConnectProcessor.handleQuery(ConnectProcessor.java:336) ~[starrocks-fe.jar:?]
at com.starrocks.qe.ConnectProcessor.dispatch(ConnectProcessor.java:530) ~[starrocks-fe.jar:?]
at com.starrocks.qe.ConnectProcessor.processOnce(ConnectProcessor.java:838) ~[starrocks-fe.jar:?]
at com.starrocks.mysql.nio.ReadListener.lambda$handleEvent$0(ReadListener.java:69) ~[starrocks-fe.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
当执行 SHOW FRONTENDS
时,如果找不到 Leader FE 节点,则可能有以下几个原因
- 如果观察到超过一半的 FE 节点正在进行 Full GC,并且持续时间明显较长。
- 或者,如果日志包含关键字
java.lang.OutOfMemoryError: Java heap space
。
这是因为内存不足。您需要增加 JVM 内存分配。
10. 最后的措施
仅当上述所有解决方案均不起作用时,您才可以尝试以下解决方案作为最后的措施。
此解决方案仅适用于极端情况,例如
- 大多数 Follower 节点无法重启。
- 由于 BDBJE 的 Bug,Follower 节点无法执行 Leader 选举。
- 除上述章节中提到的异常之外的其他异常。
请按照以下步骤恢复元数据
-
停止所有 FE 节点。
-
备份所有 FE 节点的元数据目录
meta_dir
。 -
在托管 FE 节点的所有服务器上运行以下命令,以识别具有最新元数据的节点。
# You need to specify the exact .jar package the node uses in the command
# as the package varies according to the StarRocks version.
java -jar fe/lib/starrocks-bdb-je-18.3.16.jar DbPrintLog -h meta/bdb/ -vd示例输出
<DbPrintLog>
file 0x3b numRepRecords = 24479 firstVLSN = 1,434,126 lastVLSN = 1,458,604
file 0x3c numRepRecords = 22541 firstVLSN = 1,458,605 lastVLSN = 1,481,145
file 0x3d numRepRecords = 25176 firstVLSN = 1,481,146 lastVLSN = 1,506,321
......
file 0x74 numRepRecords = 26903 firstVLSN = 2,927,458 lastVLSN = 2,954,360
file 0x75 numRepRecords = 26496 firstVLSN = 2,954,361 lastVLSN = 2,980,856
file 0x76 numRepRecords = 18727 firstVLSN = 2,980,857 lastVLSN = 2,999,583
... 0 files at end
First file: 0x3b
Last file: 0x76
</DbPrintLog>具有最大
lastVLSN
值的节点具有最新的元数据。 -
从 fe/meta/image/ROLE 文件中找到具有最新元数据的 FE 节点的作用 (Follower 或 Observer)
cat fe/meta/image/ROLE
#Fri Jan 19 20:03:14 CST 2024
role=FOLLOWER
hostType=IP
name=172.26.92.154_9312_1705568349984如果多个节点具有最新的元数据,建议继续使用 Follower 节点。如果多个 Follower 节点具有最新的元数据,您可以选择其中任何一个。
-
根据您在上一步中选择的 FE 节点的作用执行相应的操作。
- 继续使用 Follower 节点
- 继续使用 Observer 节点
如果 Follower 节点具有最新的元数据,请执行以下操作
-
将以下配置添加到 fe.conf
bdbje_reset_election_group = true
-
重启节点,并检查您的数据和元数据是否完整。
-
检查当前 FE 节点是否为 Leader FE 节点。
SHOW FRONTENDS;
- 如果字段
Alive
为true
,则此 FE 节点已正确启动并添加到集群。 - 如果字段
Role
为LEADER
,则此 FE 节点是 Leader FE 节点。
- 如果字段
-
如果数据和元数据完整,并且节点的作用是 Leader,则您可以删除先前添加的配置并重启节点。
如果 Observer 节点具有最新的元数据,请执行以下操作
-
在 fe/meta/image/ROLE 文件中将 FE 节点的作用从
OBSERVER
更改为FOLLOWER
。 -
将以下配置添加到 fe.conf
bdbje_reset_election_group = true
-
重启节点,并检查您的数据和元数据是否完整。
-
检查当前 FE 节点是否为 Leader FE 节点。
SHOW FRONTENDS;
- 如果字段
Alive
为true
,则此 FE 节点已正确启动并添加到集群。 - 如果字段
Role
为LEADER
,则此 FE 节点是 Leader FE 节点。
- 如果字段
-
如果数据和元数据完整,并且节点的作用是 Leader,则您可以删除先前添加的配置。但是,不要重启节点。
-
向集群添加一个新的 Follower 节点(在新服务器上)。
ALTER SYSTEM ADD FOLLOWER "<new_follower_host>:<new_follower_edit_log_port>";
-
使用临时 Leader FE 节点作为帮助程序在新服务器上启动一个新的 FE 节点。
# Replace <leader_ip> with the IP address (priority_networks)
# of the Leader FE node, and replace <leader_edit_log_port> (Default: 9010) with
# the Leader FE node's edit_log_port.
./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon -
新的 FE 节点成功启动后,检查两个 FE 节点的状态和作用
SHOW FRONTENDS;
- 如果字段
Alive
为true
,则此 FE 节点已正确启动并添加到集群。 - 如果字段
Role
为FOLLOWER
,则此 FE 节点是 Follower FE 节点。 - 如果字段
Role
为LEADER
,则此 FE 节点是 Leader FE 节点。
- 如果字段
-
如果新的 Follower 在集群中成功运行,则您可以停止所有节点。
-
将以下配置添加到仅新的 Follower 的 fe.conf 中
-
对于 StarRocks v2.5、v3.0、v3.1.9 和更早的补丁版本,以及 v3.2.4 和更早的补丁版本
metadata_failure_recovery = true
-
对于 StarRocks v3.1.10 和更高版本的补丁版本,v3.2.5 和更高版本的补丁版本,以及 v3.3 和更高版本
bdbje_reset_election_group = true
-
-
重启新的 Follower 节点,并检查您的数据和元数据是否完整。
-
检查当前 FE 节点是否为 Leader FE 节点。
SHOW FRONTENDS;
- 如果字段
Alive
为true
,则此 FE 节点已正确启动并添加到集群。 - 如果字段
Role
为LEADER
,则此 FE 节点是 Leader FE 节点。
- 如果字段
-
如果数据和元数据完整,并且节点的作用是 Leader,则您可以删除先前添加的配置并重启节点。
-
清除您想要添加回集群的 FE 节点的元数据目录
meta_dir
。 -
使用新的 Leader FE 节点作为帮助程序启动新的 Follower 节点。
# Replace <leader_ip> with the IP address (priority_networks)
# of the Leader FE node, and replace <leader_edit_log_port> (Default: 9010) with
# the Leader FE node's edit_log_port.
./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon -
将 Follower 节点添加回集群。
ALTER SYSTEM ADD FOLLOWER "<new_follower_host>:<new_follower_edit_log_port>";
在所有节点都添加回集群后,元数据已成功恢复。
使用元数据备份在新 FE 节点上恢复元数据
如果您想要使用元数据备份启动一个新的 FE 节点,请按照以下步骤操作
-
将备份元数据目录
meta_dir
复制到新的 FE 节点。 -
在 FE 节点的配置文件中,将
bdbje_reset_election_group
设置为true
。bdbje_reset_election_group = true
-
启动 FE 节点。
./fe/bin/start_fe.sh
-
检查当前 FE 节点是否为 Leader FE 节点。
SHOW FRONTENDS;
如果字段
Role
为LEADER
,则此 FE 节点是 Leader FE 节点。确保其 IP 地址是当前 FE 节点的 IP 地址。 -
如果数据和元数据完整,并且节点的作用是 Leader,则您必须删除配置
bdbje_reset_election_group
并重启节点。 -
现在您已成功使用元数据备份启动一个新的 Leader FE 节点。您可以使用新的 Leader FE 节点作为帮助程序添加新的 Follower 节点。
# Replace <leader_ip> with the IP address (priority_networks)
# of the Leader FE node, and replace <leader_edit_log_port> (Default: 9010) with
# the Leader FE node's edit_log_port.
./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon
元数据恢复相关配置
元数据恢复完成后,您必须删除以下配置。