rocksdb-doc-cn

介绍

每个应用都是独特的,并且可能都需要一些来自RocksDB的并发保护。RocksDB中每个提交的记录都会被持久化。没有提交的消息会被记录到WAL(Write-Ahead-Log.md)。当rocksdb被安全地关闭,所有未提交的记录都会在关闭前提交,因此一致性总是可以保证的。当rocksDB被kill掉或者机器重启,RocksDB在重启的时候需要将自己恢复到一致性的状态。

恢复过程中一个非常重要的操作是重放WAL中没有提交的记录。不同的WAL恢复模式会有不同的重放行为。

WAL恢复模式

kTolerateCorruptedTailRecords

在这种模式,WAL重放忽略任何日志尾部的错误。这么做的原因是,在一个不完整的关机下,日志尾部可能有些没有写完的数据。这是一个启发式的模式,系统无法区分到底是日志尾部数据损坏还是没有写完。其他的IO错误,会被认为是数据损坏。

这个模式对大部分应用都是可以接受的,因为他在一个不完整的关机之后重启RocksDB和一致性之间,提供了一个合理的平衡。

kAbsoluteConsistency

在这个模式下,WAL重放的时候,任何IO错误都会被认为数据错误。这个模式对于那些不能接受任何一个数据丢失以及/或者有其他方式来恢复数据的应用,是非常理想的。

kPointInTimeConsistency

在这个模式,WAL重放会在遇到一个IO错误的时候停止。系统会恢复到一个一致性能得到保证的特定时间点。这对于有复制的系统来说很好用。其他复制集的数据可以用来重放从“特定时间点”之后的数据以恢复系统。

kSkipAnyCorruptedRecord

在这种模式,读取日志过程中,任何IO错误都会被忽略。系统尝试恢复尽可能多的数据。适用于灾难恢复。

看到这里或许你有建议或者疑问或者指出错误,请留言评论! 多谢! 你的评论非常重要!也可以帮忙点赞收藏转发!多谢支持! 觉得写的不错那就给点吧, 在线乞讨 微信转账