无论是RMSDB,还是NOSQL DB,如何最大程度上保证故障时的数据恢复,都涉及到数据持久化的技术。本位重点说明write-ahead-log与append-only-file这两种持久化机制的原理。
write-ahead-log,WAL日志,是数据库中一种高效的日志算法。从数据库原理而言,它实现的是redo日志模式。即修改数据库时,不直接修改数据库内容,而是将修改完的数据写入日志同步到磁盘上,这样对其他读进程就没有影响。如果数据库崩溃,重启后扫描日志文件,然后更新到数据库中。为了提高效率,WAL日志模式提供checkpoint操作,来定时进行数据更新操作。
以SQLite、MapDB为例,WAL的实现就是是按照上面原理来的。在更新数据页时,会将更新完的页先同步到磁盘上,并定时进行checkpoint操作。读数据库的时候,为了读到最新的页面,需要扫描日志文件,得到最新的数据页。为了提高日志文件扫描速度,还需要设计一些wal-index索引来加快对WAL日志的操作速度。
append-only-file,AOF日志,以Redis为例。在Redis异常死掉时,最近的数据会丢失(丢失数据的多少视你save策略而定),当业务量很大时,可能丢失的数据会很多。Append-only方法可以做到全部数据不丢失,但Redis的性能就要差些。AOF就可以做到全程持久化,开启AOF之后,Redis每执行一个修改数据的命令,都会把它添加到aof文件中,当Redis重启时,将会读取AOF文件进行“Log-Rewriting 重放”以恢复到Redis关闭前的最后时刻。
Log-Rewriting随着AOF文件越来越大,重放速度会越来越慢。但是AOF中如同流水账一样,会记录很多某一个key的全部变化过程。因此Redis有了一种比较有意思的特性:会在后台重建AOF文件,而不会影响client端操作。在任何时候执行BGREWRITEAOF命令,会对当前AOF中的数据进行整合,为每个key重新生成最短序列的AOF文件,这些数据完全可以用于构建当前某个Key的数据情况,而不会存在多余的变化情况(比如状态变化,计数器变化等),从而缩小了AOF文件的大小。所以当使用AOF时,redis推荐同时使用BGREWRITEAOF。
AOF文件刷新的方式,有三种,参考配置参数appendfsync :appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件,非常非常慢,但也非常安全;appendfsync everysec每秒钟都调用fsync刷新到AOF文件,很快,但可能会丢失一秒以内的数据;appendfsync no依靠OS进行刷新,redis不主动刷新AOF,这样最快,但安全性就差。默认并推荐每秒刷新,这样在速度和安全上都做到了兼顾。
LOG Rewrite的工作原理:同样用到了copy-on-write:首先redis会fork一个子进程;子进程将最新的AOF写入一个临时文件;父进程增量的把内存中的最新执行的修改写入(这时仍写入旧的AOF,rewrite如果失败也是安全的);当子进程完成rewrite临时文件后,父进程会收到一个信号,并把之前内存中增量的修改写入临时文件末尾;这时redis将旧AOF文件重命名,临时文件重命名,开始向新的AOF中写入。