[Question] OOM导致图数据文件损坏而无法启动hugegraph

[ka1serdom]

Problem Type (问题类型)

server status (启动/运行异常)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.0.0 (Apache Release Version)
• Backend: RocksDB

Your Question (问题描述)

系统日志

hugegraph启动报错

[dosubot]

Hello @ka1serdom! I'm here to assist you with any bugs or questions you might have while you wait for a human maintainer. Feel free to ask away!

I found a similar unsolved discussion regarding RocksDB memory occupation issues ^[1]. Additionally, there is a closed issue related to RocksDB not being able to open after a timeout during HugeGraphServer restart, but no solution was found in the comments ^[2].

To address the Out-Of-Memory (OOM) errors causing corruption of graph data files when using RocksDB as the backend, consider the following steps:

1. Increase Memory Allocation: Adjust the JVM heap size using -Xmx and -Xms parameters to ensure sufficient memory is allocated.

2. Optimize RocksDB Configuration: Modify settings such as write_buffer_size, max_write_buffer_number, and block_cache_size in the HugeGraph configuration file. For example, set rocksdb.write_buffer_size to 128MB and rocksdb.max_write_buffer_number to 6.

3. Use Optimized Disk Paths: Configure HugeGraph to use optimized disk paths for different tables if multiple disks are available, using the rocksdb.data_disks option.

4. Snapshot and Restore: Utilize the snapshot feature to restore data if files are corrupted, using createSnapshot and resumeSnapshot methods in the RocksDBStore class.

5. Regular Compaction: Perform regular compaction of the RocksDB database to reclaim space and improve performance using the compact method.

6. Monitor and Log: Enable detailed logging to monitor memory usage and identify bottlenecks, setting rocksdb.log_level to DEBUG for more detailed logs.

These steps should help mitigate OOM errors and prevent data corruption ^[3][4].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[imbajin]

@ka1serdom 首先, OOM 的问题在 1.5.0 增加了堆内 + 堆外的双重管控. 也增加了首个 Raft + RocksDB 的分布式的存储, 建议早升级

refer: #2650 (默认开启堆内, 尽量避免 OOM)

其次, 数据库文件倒也不是损坏了, 可能是因为进程 kill 导致两边不一致了 (WAL -> SST 是一个经典过程)

然后引用一下 LLM 的回复你可以参考, 最简单的就是备份之后先删掉 wal 这个临时文件:

从你提供的日志信息来看，RocksDB 启动失败的主要原因是：

**`org.rocksdb.RocksDBException: SST file is ahead of WALs in CF hugegraph01/data/g`**

这是一个关键的错误信息。它表明 RocksDB 在尝试打开列族 (Column Family) `hugegraph01/data/g` 时，发现某些 SST (Sorted String Table) 文件的时间戳比 WAL (Write Ahead Log) 文件中的记录还要新。

**问题原因分析：**

这种情况通常发生在以下几种情况下：

1.  **不正常的关闭或数据损坏：**
    * 如果 RocksDB 或其宿主应用程序在写入过程中异常终止（例如，进程被强行杀死、系统崩溃、断电），WAL 文件可能没有完全记录最新的操作，或者 SST 文件可能已经写入了 WAL 未来得及记录的数据。
    * 文件系统损坏或磁盘错误也可能导致数据不一致。
2.  **手动操作或恢复不当：**
    * 如果曾经手动从备份中恢复数据，或者在不同的 RocksDB 实例之间移动数据文件，并且操作不当，可能会导致 SST 和 WAL 文件之间的不一致。
    * 尝试使用比数据更新的 RocksDB 版本打开旧数据，或者反之，有时也可能触发此类问题，尽管更常见的是版本不兼容的错误。
3.  **并发写入问题或 Bug：**
    * 尽管不太常见，但 RocksDB 本身或其上层应用的并发控制逻辑中如果存在 bug，也可能导致数据写入顺序的混乱。

**如何修复：**

修复这个问题通常需要谨慎操作，因为涉及到数据一致性。以下是一些可能的修复方法，**在进行任何操作前，强烈建议备份当前的 RocksDB 数据目录。**

1.  **RocksDB 自动修复机制 (通常是首选)：**
    * RocksDB 在启动时会尝试进行一些自动修复。根据错误信息，它似乎已经尝试打开并遇到了这个问题。
    * 你可以尝试配置 RocksDB 在启动时进行更积极的修复。相关的 RocksDB 选项可能包括：
        * `DBOptions::wal_recovery_mode`: 这个选项控制 WAL 恢复的模式。可以尝试设置为 `kTolerateCorruptedTailRecords` 或 `kAbsoluteConsistency` 之外的其他值，但这需要对 RocksDB 的恢复机制有深入了解，并意识到可能的数据丢失风险。
        * `DBOptions::paranoid_checks`: 确保这个选项设置为 `true` (通常是默认值)，以便尽早发现问题。
    * **注意:** 简单地重启可能不会解决这个问题，因为错误表明数据本身存在不一致。

2.  **使用 RocksDB 工具 (ldb)：**
    * RocksDB 提供了一个名为 `ldb` 的命令行工具，可以用来检查和修复数据库。
    * 你可以尝试使用 `ldb repair /path/to/your/rocksdb_data_directory` 命令。
    * 例如，在你的情况下，路径可能是 `/mnt/vd0/hugegraph/hugegraph01/data/g` 的父目录，或者直接是这个目录，取决于 `ldb repair` 如何处理列族。你需要查阅 `ldb` 的文档来确定正确的用法。
    * **警告：** `ldb repair` 可能会丢弃损坏或不一致的数据以使数据库能够打开。

3.  **删除 WAL 文件 (有数据丢失风险)：**
    * **这是一个有风险的操作，可能会导致最近未持久化到 SST 文件的数据丢失。**
    * 如果错误是 "SST file is ahead of WALs"，意味着某些 SST 文件比 WAL 记录的更新。理论上，如果这些 SST 文件是有效的，那么 WAL 中的旧记录可能不再重要。
    * 你可以尝试备份并删除位于 `hugegraph01/data/g` 目录下的 WAL 文件 (通常以 `.log` 为后缀)。然后尝试重启 RocksDB。RocksDB 可能会从现有的 SST 文件重建状态。
    * **再次强调，这可能会导致数据丢失，仅在了解风险并已备份数据的情况下尝试。**

4.  **从备份恢复：**
    * 如果你有最近的、已知良好的备份，那么最安全的做法是从备份中恢复整个 RocksDB 数据目录。这是避免数据丢失的最佳方法。

5.  **检查文件系统和硬件：**
    * 运行文件系统检查 (如 `fsck`) 来排除底层文件系统损坏的可能性。
    * 检查磁盘的健康状况，确保没有硬件故障。

**针对你的日志中的其他信息：**

* `WARN o.a.h.c.HugeConfig - The config option cassandra.port is redundant, please ensure it has been registered`： 这类警告信息表明 HugeGraph 的某些配置项可能是多余的或者已经有默认注册，建议检查 HugeGraph 的配置文件，清理这些冗余配置，但这与 RocksDB 的启动失败没有直接关系。
* `java.lang.RuntimeException: Graph 'hugegraph01' can't be loaded: '../conf/graphs/hugegraph01.properties'`：这个错误发生在 RocksDB 启动失败之后，因为 HugeGraph 依赖于底层的 RocksDB 存储。一旦 RocksDB 无法启动，HugeGraph 自然也无法加载。

**行动步骤建议：**

1.  **备份数据：** 在进行任何操作之前，请务必完整备份 `/mnt/vd0/hugegraph/hugegraph01/data/` 目录。
2.  **尝试 `ldb repair`：**
    ```bash
    # 找到 ldb 工具的位置，通常随 RocksDB 一起安装
    # 假设你的数据目录是 /mnt/vd0/hugegraph/hugegraph01/data
    ldb repair --db=/mnt/vd0/hugegraph/hugegraph01/data
    # 或者针对特定的列族，但通常修复是针对整个数据库实例的
    ```
    请查阅 `ldb` 的具体用法。
3.  **如果 `ldb repair` 失败或者你愿意承担一定的数据丢失风险：**
    * 备份 WAL 文件：将 `hugegraph01/data/g` 目录下的所有 `.log` 文件移动到备份位置。
    * 尝试重启应用程序。
4.  **如果上述方法都无效，且有备份：** 从备份中恢复。
5.  **如果无法修复且没有可用备份：** 你可能需要接受一定程度的数据丢失，或者寻求更专业的 RocksDB 数据恢复服务。在这种情况下，可能需要分析 SST 文件的内容来尝试手动重建尽可能多的数据，但这非常复杂。

[github-actions]

Due to the lack of activity, the current issue is marked as stale and will be closed after 20 days, any update will remove the stale label