You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we use rocksdb through C API, the WAL config is kept default, underlying file system is a default EXT4 on NVME SSD
after a terminal disconnect, we try to reopen the DB and found some data is wrong, then I check and find WAL may be corrupted as LOG shows:
as far as I know, RocksDB promises data consistance with WAL enabled, and EXT4 has is own journal, too, why data still happens? Will changing WAL recovery mode to absolute_consistancy help? In our use case, we prefer no data than wrong data.
The text was updated successfully, but these errors were encountered:
we use rocksdb through C API, the WAL config is kept default, underlying file system is a default EXT4 on NVME SSD
after a terminal disconnect, we try to reopen the DB and found some data is wrong, then I check and find WAL may be corrupted as LOG shows:
as far as I know, RocksDB promises data consistance with WAL enabled, and EXT4 has is own journal, too, why data still happens? Will changing WAL recovery mode to absolute_consistancy help? In our use case, we prefer no data than wrong data.
The text was updated successfully, but these errors were encountered: