postgresql9.6之WAL(Write Ahead Log)

oracle 数据库中存在重做日志文件(redo log),其作用是保证数据的一致性和事务的完整性，防止在系统崩溃时最近的事务无法恢复。在postgresql中引入了WAL(write ahead log),作用相同。有不同之处的是postgresql数据库可以通过调整WAL参数控制日志写入磁盘的先后顺序。先将日志写入磁盘能够完全保证数据的 完整性，在崩溃时可以恢复最近的事务；后写入磁盘，很难保证在崩溃时事务能够得到恢复，数据的结果也很难保证是真实正确的。了解postgresql 的WAL参数是非常必要的，直接关乎到了数据库的可用性。
WAL相关参数：

postgresql数据库的配置文件

# - Settings -

wal_level = minimal                     # minimal,replica,or logical
                                        # (change requires restart)
#fsync = on                             # flush data to disk for crash safety
                                                # (turning this off can cause
                                                # unrecoverable data corruption)
#synchronous_commit = on                # synchronization level;
                                        # off,local,remote_write,remote_apply,or on
#wal_sync_method = fsync                # the default is the first option
                                        # supported by the operating system:
                                        # open_datasync
                                        # fdatasync (default on Linux)
                                        # fsync
                                        # fsync_writethrough
                                        # open_sync
#full_page_writes = on                  # recover from partial page writes
#wal_compression = off                  # enable compression of full-page writes
#wal_log_hints = off                    # also do full page writes of non-critic
al updates
                                        # (change requires restart)
#wal_buffers = -1                       # min 32kB,-1 sets based on shared_buffers
                                        # (change requires restart)
#wal_writer_delay = 200ms               # 1-10000 milliseconds
#wal_writer_flush_after = 1MB           # 0 disables

#commit_delay = 0                       # range 0-100000,in microseconds
#commit_siblings = 5                    # range 1-1000

# - Checkpoints -

#checkpoint_timeout = 5min              # range 30s-1d
#max_wal_size = 1GB
#min_wal_size = 80MB
#checkpoint_completion_target = 0.5     # checkpoint target duration,0.0 - 1.0
#checkpoint_flush_after = 0             # 0 disables,# default is 256kB on linux,0 otherwise
#checkpoint_warning = 30s               # 0 disables

• wal_level：

控制wal存储的级别。wal_level决定有多少信息被写入到WAL中。 默认值是最小的（minimal），其中只写入从崩溃或立即关机中恢复的所需信息。replica 增加 wal 归档信息 同时包括 只读服务器需要的信息。（9.6 中新增，将之前版本的 archive 和 hot_standby 合并）

• 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数据的内存空间。最小32K。

• wal_writer_delay：
  WAL writer进程的间歇时间。默认值是200ms。准确的配置应该根据自身系统的运行状况。如果时间过长可能造成WAL buffer的内存不足；反之过小将会引起WAL的不断的写入，对磁盘的IO也是很大考验。
• wal_writer_flush_after
  wal write的字节数超过配置的阈值(wal_writer_flush_after)时,触发fsync，默认值为1MB，如果设置为0，关闭该特性（9.6版本新增的参数）
• 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。

• checkpoint_timeout
  生成检查点的最大的间隔时间。
• checkpoint_completion_target
  参数表示checkpoint的完成目标，系统默认值是0.5,也就是说每个checkpoint需要在checkpoints间隔时间的50%内完成。

PostgreSQL 9.5 废弃了checkpoint_segments 参数,并引入max_wal_size 和 min_wal_size 参数,通过max_wal_size和checkpoint_completion_target 参数来控制产生多少个XLOG后触发检查点,通过min_wal_size和max_wal_size参数来控制哪些XLOG可以循环使用.

• min_wal_size
  最小的wal 空间

WAL的执行控制： 通过参数的介绍粗略的知道WAL实现写入的时候有 1,事务commit时； 2,WAL writer进程到达间歇时间时； 3,checkpoint发生时；因为在数据写入数据文件之前首先要确保日志已经写入了WAL中。