随着服务器内存的增长和更加严格的低延迟需求, 很多应用都决定将全部数据存储在内存中. 在 RocksDB 中启动一个全内存的数据库非常简单, 只需要将 RocksDB 数据目录 mount 到 tmpfs or ramfs 中即可. 即使进程挂掉了, RocksDB 也可以从 in-memory 文件系统中恢复所有的数据. 但是, 如果机器重启了会发生什么呢?
接下来会详细讲述在服务器重启后怎么恢复 in-memory RocksDB 的全部数据.
RocksDB 的每一次 update 都会写入两个位置, 一个是内存数据结构即 memtable, 另一个是 WAL.WAL 可以用来完全恢复 memtable 中的数据. 默认情况下, 当把内存表中的数据 flush 到 SST file 后, 对应的 WAL 就会被删除, 因为不需要再用这个 WAL 来恢复 memtable(已经持久化) 了. 但是, 如果 SST file 存储在 in-memory file system 里, 那么就需要这个 WAL 日志在机器重启后来恢复日志.
Options::wal_dir 是 RocksDB 存储 WAL 文件的目录. 如果将这个目录配置在 flash or disk, 机器重启后并不会丢失当前的日志文件. Options::WAL_ttl_seconds 是指这些归档后的日志文件经历多长时间后被删除. 如果设置为非零值, 无用的 log 文件会被 move 到 Options::wal_dir 目录下的 archive / 目录. 只有当 timeout 之后, 才会删除这些归档日志文件.
假设 Options::wal_dir 配置在持久化存储上, Options::WAL_ttl_seconds 配置为一天. 为了完全能够恢复 DB, 我们必须以多于每天一次的频率来备份数据库的快照信息 (包括 table files 和 metadata files).RocksDB 提供了简单的方法来支持 backup 数据库的快照.
用户应该配置 backup 过程, 避免 backup 日志文件, 因为这些文件已经安全地保存在持久化存储上了. 配置: BackupableDBOptions::backup_log_files=false
默认的 restore 过程会清除 DB 和 WAL 目录的数据. 由于在 backup 文件中没有 log 文件, 所以要确保在恢复数据库过程中不要删除 WAL 目录中的 log 文件. 当 restore 时, 配置 RestoreOptions::keep_log_file=true. 这个配置会 move 所有归档的日志文件回到 WAL 目录, RocksDB 就可以 replay 所有归档日志文件中的操作, 重建 in-memory 数据库的状态.
总之, 步骤如下:
来源: http://www.jianshu.com/p/46bb78bca726