PostgreSQL之wal日志

先看下进程

关于持久性的概念

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

简单来讲,我往银行存了100块钱,这个存钱流程走完了之后,银行必须保证我存的100块钱一直都在,能查询到,能取出来。

持久性如何实现

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

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

WalWriter进程

WalWriter进程是一个后端进程,它负责确保WAL文件被正确写入磁盘,并且它的行为可以在postgresql.conf中设置以下参数进行配置:

#------------------------------------------------------------------------------
# WRITE-AHEAD LOG
#------------------------------------------------------------------------------

# - Settings -

#wal_level = replica                    # 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-critical updates
                                        # (change requires restart)
#wal_init_zero = on                     # zero-fill new WAL files
#wal_recycle = on                       # recycle WAL files
#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           # measured in pages, 0 disables
#wal_skip_threshold = 2MB

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

【wal_level】

控制wal存储的级别。wal_level确定有多少信息被写入到WAL。默认值是replica,它添加了WAL归档信息,包括只读服务器(流复制)所需的信息。还可以将其设置为minimal,即只写入从崩溃或立即关闭中恢复所需的信息。设置为Logical允许在逻辑解码场景中完成WAL流。


【fsync】

这个参数直接控制日志是否先写到磁盘。默认值为ON(先写),这意味着系统应该通过发出wal_sync_method设置的fsync指令,来确保更改确实被刷新到磁盘。虽然关闭fsync通常可以提高性能,其直接隐患是无法保证在系统崩溃时最近的事务能够得到恢复,也就无法保证相关数据的真实与正确性


【synchronous_commit】

此参数用于配置系统是否等待WAL完全完成后再将状态信息返回给用户事务。默认值为ON,表示必须等待WAL完成后才能返回事务状态信息;配置OFF可以更快地反馈事务状态,提升性能。


【wal_sync_method】

这个参数控制WAL写入磁盘的fsync方法。默认值是fsync。可用的值包括open_datasync、fdatasync、fsync_writethrough、fsync、以及open_sync.open_datasync和open_sync,一般采用默认值即可,对于裸设备或文件系统的可选配置,在实际的使用中所带来的方便相对fsync很有限。

【full_page_writes】

指示是否将整个页面写入WAL,参数表明是否将整个page写入WAL。postgresql中数据处理过程中的位置只有内存和WAL中,在内存中的整个page中己包含更新提交的也包含没有提交的,如果不将整个page写入WAL中,在介质恢复的时候WAL中记录的数据不足以实现完整的恢复(说白了就是无法实现介质恢复时事务的回滚),写入整个page。
说到这里似乎更明白了,postgresql中不存在类似oracle的undo文件,postgresql将前滚和回滚所需的数据都写入到了WAL。不管是否写入整个page,对数据库的PITR不影响(文档也说明了),因为更新提交肯定要写入了WAL中。


【wal_buffers】

指示了用于存储WAL数据的内存空间量。系统默认值为64K。此参数还受wal_writer_delay和commit_delay这两个参数的影响。


【wal_writer_delay】

WalWriter进程的写入间隔。默认值是200毫秒。如果时间过长,可能会导致WAL缓冲区内存不足;如果时间太短,会导致WAL不断写入,增加磁盘I/O负担。


【wal_writer_flush_after】

当脏数据超过这个阈值时,它将被刷新到磁盘。


【commit_delay】

指示在WAL buffer中存储已提交的数据的时间。默认值为0毫秒,表示没有延迟;当它被设置为非零值时,在事务提交后,事务将不会被立即写入到WAL中,但它仍然存储在WAL buffer中,等待WalWriter进程定期写入磁盘。


【commit_siblings】

当事务发出提交请求时,如果数据库中的事务数量大于commit_sibling的值,事务将等待一段时间(commit_delay值);否则,事务将直接写入到WAL。系统默认值是5,这个参数还确定了commit_delay的有效性。

WAL如何工作

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

Change发生时:

  •  先将变更后内容记入WAL Buffer

  •  再将更新后的数据写入Data Buffer

Commit发生时:

  •  WAL Buffer刷新到Disk

  •  Data Buffer写磁盘推迟

Checkpoint发生时:

  •  将所有Data Buffer刷新到磁盘

Change时:

 

Commit和Checkpoint时:

 

原文地址:https://www.cnblogs.com/mingfan/p/13997390.html