postgresql9.6之WAL(Write Ahead Log)

时间:2022-10-14 12:02:24
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 中新增,将之前版本的 archivehot_standby 合并)
logical 主要用于logical decoding 场景

  • 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中记录的数据不足以实现完整的恢复(说白了就是无法实现介质恢复时事务的回滚)。
说到这里似乎更明白了,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中。