rocksdb-wal-tracking · shipping · also track_and_verify_wals_in_manifest

RocksDB WAL tracking

RocksDB WAL tracking records log metadata so recovery can detect missing or incomplete logs that checksums on surviving records alone cannot identify.

The MANIFEST-based design cannot infer loss from gaps in WAL filenames because other file types share the number sequence; enabling it later does not validate old untracked WALs. [1]

For v10.10.1, track_and_verify_wals_in_manifest defaults to false, tracks synchronized closed WALs rather than live-WAL syncs, and excludes secondary instances. The separate track_and_verify_wals option is experimental, also defaults to false, and has a RepairDB compatibility warning. [2]

WalSet::CheckWals skips entries without a recorded synced size and rejects a missing file or one shorter than that size. Equality or extra bytes pass this comparison, not all recovery checks; it is not a content checksum. [3]

During ordinary recovery the check precedes WAL replay. best_efforts_recovery bypasses it, and reopening with MANIFEST tracking off clears the previously tracked WAL metadata. Disabling the check does not repair missing data. [4]

Relations

related

rocksdb-manifest, write-ahead-log, checksum

Citations

1. RocksDB project. Track WAL in MANIFEST: design and upgrade limitations. (accessed 2026-10-18)
2. RocksDB v10.10.1. DBOptions: two distinct WAL-tracking mechanisms. (accessed 2026-10-18)
3. RocksDB v10.10.1. WalSet::CheckWals: synced-size, presence and lower-bound checks. (accessed 2026-10-18)
4. RocksDB v10.10.1. DB recovery: WAL inventory check, best-efforts bypass and tracking disablement. (accessed 2026-10-18)

Further reading

5. RocksDB: who notices a missing WAL? (accessed 2026-10-18)

JSON: /data/terms/rocksdb-wal-tracking.json