postgresql之WAL(Write Ahead Log)

oracle中存在重做日志文件(redo log),其作用是保证数据的一致性和事务的完整性，防止在系统崩溃时最近的事务无法恢复。在postgresql中引入了WAL(write ahead log),作用相同。有不同之处的是postgresql数据库可以通过调整WAL参数控制日志写入磁盘的先后顺序。先将日志写入磁盘能够完全保证数据的完整性，在崩溃时可以恢复最近的事务；后写入磁盘，很难保证在崩溃时事务能够得到恢复，数据的结果也很难保证是真实正确的。看来了解postgresql的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。一般采用默认值即可，对于裸设备或文件系统的可选配置，在实际的使用中所带来的方便相对fsync很有限。
full_page_writes:
参数表明是否将整个page写入WAL。postgresql中数据处理过程中的位置只有内存和WAL中，在内存中的整个page中己包含更新提交的也包含没有提交的，如果不将整个page写入WAL中，在介质恢复的时候WAL中记录的数据不足以实现完整的恢复(说白了就是无法实现介质恢复时事务的回滚),写入整个page。
说到这里似乎更明白了,postgresql中不存在类似oracle的undo文件,postgresql将前滚和回滚所需的数据都写入到了WAL。不管是否写入整个page，对数据库的PITR不影响(文档也说明了)，因为更新提交肯定要写入了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。
WAL的执行控制：
通过参数的介绍粗略的知道WAL实现写入的时候有
1,事务commit时；
2,WAL writer进程到达间歇时间时；
3,checkpoint发生时；因为在数据写入数据文件之前首先要确保日志已经写入了WAL中。
WAL参数调整:
针对参数介绍时，说明了参数值大小时带来的性能问题。参数的配置方法并非固定，主要是根据当前系统的业务逻辑要求的严格程度，系统的更新事务负载程度，硬件的性能来决定采用何种方式对参数进行配置。

基于上述内容，欢迎大家指正，讨论。