ArangoDB 3.10 WAL日志快速占满的解决及清理问题咨询

1. ArangoDB何时自动清理WAL日志，如何提前触发清理？ #

• 自动清理时机：当WAL日志中的数据已完全刷写到RocksDB的SST持久化文件后，这些日志会被标记为可删除。此外，当归档目录大小达到rocksdb.wal-archive-size-limit阈值，或日志存活时间超过rocksdb.wal-ttl-seconds设置的时长时，也会自动触发清理。
• 提前触发清理：
  • 调用ArangoDB管理API：执行POST /_admin/rocksdb/flushWAL强制将未刷写的WAL数据写入SST，之后旧WAL文件会被自动清理。
  • 调整配置参数：缩小rocksdb.wal-archive-size-limit或rocksdb.wal-ttl-seconds，让清理逻辑更频繁触发（需权衡性能影响）。

2. 设置rocksdb.wal-archive-size-limit后，实际归档大小低于配置上限却触发警告的原因？ #

这个警告的触发逻辑并非仅依赖归档目录的实时总大小，可能的原因包括：

• 序列连续性校验：RocksDB会跟踪WAL文件的序列完整性，当新生成的WAL文件导致归档序列的预估总大小即将超过上限时，会提前强制删除旧文件，即使当前实际大小未达标。
• 路径配置不一致：检查rocksdb.wal-archive-path是否指向日志中显示的/archive目录，若配置路径与实际归档路径不符，统计的大小会出现偏差。
• 内部计算逻辑：RocksDB的大小统计可能包含临时文件或未完全写入的文件，或者采用预估未来归档容量的方式，而非实时计算当前目录大小，导致提前触发警告。

3. 降低rocksdb.wal-archive-size-limit的后果？能否完全关闭WAL归档？WAL归档是否影响事务安全？ #

• 降低阈值的后果：会更频繁清理旧归档WAL，减少磁盘占用，但会缩短可恢复的时间窗口（如无法用旧归档进行点-in-time恢复）；高写入场景下可能增加IO负载，因频繁执行文件删除操作。
• 完全关闭归档：可以设置rocksdb.wal-archive-size-limit=0或rocksdb.wal-ttl-seconds=0，此时旧WAL文件在刷写到SST后会直接被删除，不会进入归档目录。
• 事务安全与WAL归档的关系：事务安全性由活跃WAL文件保障——未刷写到SST的事务会记录在活跃WAL中，断电重启时ArangoDB会通过活跃WAL恢复未完成事务，保证ACID特性。归档WAL是已持久化到SST的日志副本，主要用于增量备份、点-in-time恢复或SST损坏时的数据修复，关闭归档不会影响断电场景下的事务安全。

4. 如何实现无警告限制WAL归档大小，并加快清理速度？ #

可以通过以下配置和操作实现：

• 对齐归档路径：确保rocksdb.wal-archive-path配置与实际归档目录（如日志中的/archive）一致，避免大小统计偏差。
• 组合时间与大小限制：同时设置rocksdb.wal-ttl-seconds（如3600秒，即1小时）和rocksdb.wal-archive-size-limit，让清理优先基于时间阈值，减少因容量预估触发的强制删除警告。
• 提升刷写性能：调整rocksdb.max-background-flushes和rocksdb.max-background-compactions参数，增加后台刷写和压缩的线程数，加快WAL数据写入SST的速度，让旧WAL更快被标记为可清理。
• 定期手动刷写：按需调用POST /_admin/rocksdb/flushWAL接口，强制刷写未持久化的WAL数据，加速旧日志的清理（避免过于频繁调用，防止影响服务性能）。
• 检查文件占用：确认无其他进程锁定归档目录的文件，避免RocksDB无法正常删除文件而触发警告。

内容的提问来源于stack exchange，提问作者Admtech