每个应用都是独特的，并且可能都需要一些来自RocksDB的并发保护。RocksDB中每个提交的记录都会被持久化。没有提交的消息会被记录到WAL(Write-Ahead-Log.md)。当rocksdb被安全地关闭，所有未提交的记录都会在关闭前提交，因此一致性总是可以保证的。当rocksDB被kill掉或者机器重启，RocksDB在重启的时候需要将自己恢复到一致性的状态。
恢复过程中一个非常重要的操作是重放WAL中没有提交的记录。不同的WAL恢复模式会有不同的重放行为。
在这种模式，WAL重放忽略任何日志尾部的错误。这么做的原因是，在一个不完整的关机下，日志尾部可能有些没有写完的数据。这是一个启发式的模式，系统无法区分到底是日志尾部数据损坏还是没有写完。其他的IO错误，会被认为是数据损坏。
这个模式对大部分应用都是可以接受的，因为他在一个不完整的关机之后重启RocksDB和一致性之间，提供了一个合理的平衡。
在这个模式下，WAL重放的时候，任何IO错误都会被认为数据错误。这个模式对于那些不能接受任何一个数据丢失以及/或者有其他方式来恢复数据的应用，是非常理想的。
在这个模式，WAL重放会在遇到一个IO错误的时候停止。系统会恢复到一个一致性能得到保证的特定时间点。这对于有复制的系统来说很好用。其他复制集的数据可以用来重放从“特定时间点”之后的数据以恢复系统。
在这种模式，读取日志过程中，任何IO错误都会被忽略。系统尝试恢复尽可能多的数据。适用于灾难恢复。