PostgreSQL 预写日志机制（WAL）

关于持久性

持久性是指，事务提交后，对系统的影响必须是永久的，即使系统意外宕机，也必须确保事务提交时的修改已真正永久写入到永久存储中。

最简单的实现方法，当然是在事务提交后立即刷新事务修改后的数据到磁盘。但是磁盘和内存之间的IO操作是最影响数据库系统影响时间的，一有事务提交就去刷新磁盘，会对数据库性能产生不好影响。

WAL机制的引入，即保证了事务持久性和数据完整性，又尽量地避免了频繁IO对性能的影响。

WAL过程分析

Write-Ahead Logging，前写日志。

在MVCC的部分中，我们已经分析了PostgreSQL的存储结构：元组-文件页-物理段-表；
以及写数据的步骤：先写到缓冲区Buffer-再刷新到磁盘Disk。

WAL机制实际是在这个写数据的过程中加入了对应的写wal log的过程，步骤一样是先到Buffer，再刷新到Disk。

Change发生时：
先将变更后内容记入WAL Buffer
再将更新后的数据写入Data Buffer
Commit发生时：
WAL Buffer刷新到Disk
Data Buffer写磁盘推迟
Checkpoint发生时：
将所有Data Buffer刷新到磁盘

数据发生变动时

commit和checkpoint

WAL的好处

通过上面的分析，可以看到：

当宕机发生时，

Data Buffer的内容还没有全部写入到永久存储中，数据丢失；
但是WAL Buffer的内容已写入磁盘，根据WAL日志的内容，可以恢复库丢失的内容。

在提交时，仅把WAL刷新到了磁盘，而不是Data刷新：

从IO次数来说，WAL刷新是少量IO，Data刷新是大量IO，WAL刷新次数少得多；
从IO花销来说，WAL刷新是连续IO，Data刷新是随机IO，WAL刷新花销小得多。

因此WAL机制在保证事务持久性和数据完整性的同时，成功地提升了系统性能。

附：PostgreSQL官网文档关于WAL的翻译

官网翻译

Write-Ahead Logging是一种保证数据完整性的标准方法。简单地说，WAL的概念就是对数据文件的改变（包括表和索引）必须先写入日志，即日志记录刷新到永久储存之后，才能被写。遵循这个过程，就不需要在每个事务提交时都刷新数据页到磁盘，因为在宕机时可以用日志来恢复数据库：任何没有应用到数据页上的改动都可以根据日志记录重做。（即回滚恢复REDO）

因为WAL可以在宕机后恢复数据库文件内容，JFS（journaled file systems）对于数据文件或WAL文件的可靠存储就不是必要的了。实际上，JFS甚至会影响系统性能，尤其当它要把文件系统数据刷新到磁盘的时候。还好，JFS中的数据刷新可以在文件系统挂载选项中禁用。JFS确实提高了宕机后的root速度。

使用WAL可以显著地减少写磁盘的次数，因为只需要把日志文件刷新到磁盘就可以保证事务被提交，而不需要把事务改动过的每一个数据文件都刷新到磁盘。日志文件是连续写的，所以同步log的花销远小于刷新数据页的花销。特别是服务器要处理涉及数据存储不同部分的大量小事务时更是这样。另外，当服务器在处理大量并行小事务时，log文件一次fsync就可以提交多个事务。

WAL还使得在线备份和时间点恢复成为可能。通过归档WAL数据，我们可以恢复到WAL数据覆盖范围内的任何时间点：只需install一份数据库的物理备份，并恢复WAL日志到所需时间即可。更重要的是，这个物理备份并不必须是一个数据库状态的瞬时快照——如果一段时间的快照，那把WAL日志也恢复成那一段时间的即可。

PostgreSQL的WAL原理和Oracle、SQL Server 相似。

原文