??隨著服務器內存的增長和更加嚴格的低延遲需求，很多應用都決定將全部數(shù)據(jù)存儲在內存中。在RocksDB中啟動一個全內存的數(shù)據(jù)庫非常簡單，只需要將RocksDB數(shù)據(jù)目錄mount到tmpfs or ramfs中即可。即使進程掛掉了，RocksDB也可以從in-memory文件系統(tǒng)中恢復所有的數(shù)據(jù)。但是，如果機器重啟了會發(fā)生什么呢？
??接下來會詳細講述在服務器重啟后怎么恢復in-memory RocksDB的全部數(shù)據(jù)。
??RocksDB的每一次update都會寫入兩個位置，一個是內存數(shù)據(jù)結構即memtable，另一個是WAL。WAL可以用來完全恢復memtable中的數(shù)據(jù)。默認情況下，當把內存表中的數(shù)據(jù)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，我們必須以多于每天一次的頻率來備份數(shù)據(jù)庫的快照信息（包括table files 和 metadata files）。RocksDB提供了簡單的方法來支持backup 數(shù)據(jù)庫的快照。
??用戶應該配置backup過程，避免backup 日志文件，因為這些文件已經安全地保存在持久化存儲上了。配置： BackupableDBOptions::backup_log_files=false
??默認的restore過程會清除DB和WAL目錄的數(shù)據(jù)。由于在backup文件中沒有l(wèi)og文件，所以要確保在恢復數(shù)據(jù)庫過程中不要刪除WAL目錄中的log文件。當restore時，配置RestoreOptions::keep_log_file=true。這個配置會move所有歸檔的日志文件回到WAL目錄，RocksDB就可以replay所有歸檔日志文件中的操作，重建in-memory 數(shù)據(jù)庫的狀態(tài)。
總之，步驟如下：
- 將DB目錄設置為mount 到tmpfs或者ramfs的位置
- 設置Options::wal_log為持久化存儲上的目錄
- 設置Options::WAL_ttl_seconds為T second
- 每隔T/2 second，backup RocksDB ，產生snapshot文件，使用的配置需要設置:BackupableDBOptions::backup_log_files = false
- 當丟失數(shù)據(jù)時，使用配置 RestoreOptions::keep_log_file = true來從backup中恢復數(shù)據(jù)。
