PostgreSQL的WAL机制（转）

 

转发来源：

https://www.jianshu.com/p/a37ceed648a8

https://www.cnblogs.com/daduxiong/archive/2010/09/30/1839533.html

 

WAL：Write-Ahead Logging

 

为何进入WAL？

持久性是指，事务提交后，对系统的影响必须是永久的，即便系统意外宕机，也必须确保事务提交时的修改已真正永久写入到永久存储中。最简单的实现方法，固然是在事务提交后当即刷新事务修改后的数据到磁盘。可是磁盘和内存之间的IO操做是最影响数据库系统影响时间的，一有事务提交就去刷新磁盘，会对数据库性能产生很差影响。

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

WAL的概念就是对数据文件的改变（包括表和索引）必须先写入日志，即日志记录刷新到永久储存以后，才能被写。遵循这个过程，就不须要在每一个事务提交时都刷新数据页到磁盘，由于在宕机时能够用日志来恢复数据库：任何没有应用到数据页上的改动均可以根据日志记录重作。

 

WAL如何工做？

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

Change发生时：

•  先将变动后内容记入WAL Buffer
•  再将更新后的数据写入Data Buffer

Commit发生时：

•  WAL Buffer刷新到Disk
•  Data Buffer写磁盘推迟

Checkpoint发生时：

•  将全部Data Buffer刷新到磁盘

Change时：

Commit和Checkpoint时

 

 WAL的好处？

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

WAL还使得在线备份和时间点恢复成为可能。经过归档WAL数据，咱们能够恢复到WAL数据覆盖范围内的任什么时候间点：只需install一份数据库的物理备份，并恢复WAL日志到所需时间便可。更重要的是，这个物理备份并没必要须是一个数据库状态的瞬时快照—若是一段时间的快照，那把WAL日志也恢复成那一段时间的便可。

 

WAL的配置参数：

• fsync：该参数直接控制日志是否先写入磁盘。默认值是ON(先写入)。开启该值时代表，更新数据写入磁盘时系统必须等待WAL的写入完成。能够配置该参数为OFF，更新数据写入磁盘彻底不用等待WAL的写入完成，没有了等待的时间，显然接下来的工做可以更早的去作，节省了时间，提升了性能。其直接隐患是没法保证在系统崩溃时最近的事务可以获得恢复，也就没法保证相关数据的真实与正确性。
• synchronous_commit：参数代表是否等待WAL完成后才返回给用户事务的状态信息。默认值是ON，代表必须等待WAL完成后才返回事务状态信息。配置OFF值可以更快的反馈回事务状态。因参数只是控制事务的状态反馈，所以对于数据的一致性不存在风险。但事务的状态信息影响着数据库的整个状态。该参数能够灵活的配置，对于业务没有严谨要求的事务能够配置为OFF，可以为系统的性能带来不小的提高。
• wal_sync_method：WAL写入磁盘的控制方式，默认值是fsync。可选用值：open_datasync,fdatasync,fsync_writethrough,fsync,open_sync。
• full_page_writes：代表是否将整个page写入WAL。
• wal_buffers：用于存放WAL数据的内存空间。系统默认值是64K，执行一个大的事务确定受到影响，应该适当的增大该参数。相似oracle中的log buffer。该参数还受如下几个参数影响。
• wal_writer_delay：WAL writer进程的间歇时间。默认值是200ms。准确的配置应该根据自身系统的运行情况。若是时间过长可能形成WAL buffer的内存不足；反之太小将会引发WAL的不断的写入，对磁盘的IO也是很大考验。
• commit_delay：表示了一个已经提交的数据在WAL buffer中存放的时间，单位ms，默认值是0，不用延迟。非0值表示可能存在多个事务的WAL同时写入磁盘。若是设置为非0，代表了某个事务执行commit后不会当即写入WAL中，而仍存放在WAL buffer中，这样对于后面的事务申请WAL buffer时很是不利，尤为是提交事务较多的高峰期，可能引发WAL buffer内存不足。若是内存足够大，能够尽可能延长该参数值，可以使数据集中写入这样下降了系统的IO，提升了性能。一样若是此时崩溃数据面临着丢失的危险。我的建议采用默认值，同时将WAL文件存放在IO性能好的磁盘上。
• commit_siblings：该参数很是有意思，该参数还决定了commit_delay的有效性。系统默认值是5。表示当一个事务发出提交请求，此时数据库中正在执行的事务数量大于5，则该事务将等待一段时间（commit_delay的值），反之，该事务则直接写入WAL。