元数据恢复
本主题描述了当 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 错误
您可以通过以下错误消息识别 VLSN 错误:
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
- 此错误已在 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) 的 BDBJE 版本不匹配时,会发生此问题。
您可以按照以下步骤解决此问题:
-
删除发生故障的 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 节点上的元数据落后于已经完成自身 CheckPoint 的 Leader 节点。Follower 节点无法对其元数据执行增量更新,因此需要完全元数据同步。
- 原始 Leader 节点写入并检查点(checkpoint)其元数据,但在挂起前未能同步到 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 社区的技术专家寻求帮助,因为此解决方案可能会导致**数据丢失**。
您可以按照以下步骤解决此问题:
忽略错误日志 ID(首选)
-
关闭所有 FE 节点。
-
备份所有 FE 节点的元数据目录。
-
在日志中定位错误的日志 ID。下面日志中的
xxx代表错误的日志 ID。got interrupt exception or inconsistent exception when replay journal xxx, will exit -
将以下配置添加到所有 fe.conf 文件中并启动 FE 节点。
metadata_journal_skip_bad_journal_ids=xxx -
如果仍然启动失败,请通过步骤 3 识别新的失败日志 ID,将其添加到 fe.conf 中,然后使用先前配置不变的情况下重启节点。
metadata_journal_skip_bad_journal_ids=xxx,yyy -
如果执行上述步骤后系统仍然无法启动,或者失败的日志 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 中配置的不同,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. 闩锁超时。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 的错误,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
与元数据恢复相关的配置
一旦元数据恢复完成,您必须删除以下配置: