PostgreSQL配置文件--WAL

3 WAL WRITE AHEAD LOG

3.1 Settings

3.1.1 fsync

字符串默认： fsync = on   开启后强制把数据同步更新到磁盘，可以保证数据库将在OS或者硬件崩溃的后恢复到一个一致的状态。虽然关闭，可以提升数据库性能，但无法保证数据库崩溃后数据一致性。通常情况下需要打开这个参数，除非能经受掉电或硬件故障带来的数据丢失，否则不要关闭。

3.1.2 wal_level

字符型默认： wal_level = replica ，minimal、replica、logical三选一重启数据库生效预写日志模式在写入频繁的场景中，会产生大量的WAL日志，而且WAL日志量会远远超过实际更新的数据量。叫做“WAL写放大”。造成WAL写放大的主要原因有2点。    1、在checkpoint之后第一次修改页面，需要在WAL中输出整个page，即全页写(full page writes)。全页写的目的是防止在意外宕机时出现的数据块部分写导致数据库无法恢复。    2、更新记录时如果新记录位置(ctid)发生变更，索引记录也要相应变更，这个变更也要记入WAL。更严重的是索引记录的变更又有可能导致索引页的全页写，进一步加剧了WAL写放大。过量的WAL输出会对系统资源造成很大的消耗，因此需要进行适当的优化。    1. 磁盘IO：WAL写入是顺序写,通常再差的硬盘对付WAL的写入速度也是绰绰有余。所以一般可以忽略。    2. 网络IO：对局域网内的复制估计还不算问题，远程复制就难说了。    3. 磁盘空间：如果做WAL归档，需要的磁盘空间也是巨大的。 版本小于或等于9.6的配置为：    minimal是仅写入崩溃或者突发关机时所需要的信息（不建议使用）。    archive是增加wal归档所需的日志（最常用）。    hot_standby是在备用服务器上增加了运行只读查询所需的信息，一般实在流复制的时候使用到。

3.1.3 wal_buffers

数字型默认： wal_buffers = -1 ，最小值32kB，-1表示和shared_buffers共用。重启数据库生效用于存放WAL数据的内存空间（日志缓存区的大小）。执行一个大事务肯定受到影响，应该适当的增大该参数，降低IO。如果遇上比较多的并发短事务，应该和commit_delay一起用

3.1.4 wal_writer_delay

数字型默认： wal_writer_delay = 200ms ，取值范围1-10000ms重启数据库生效WAL writer进程的间歇时间。决定写事务日志进程的睡眠时间。WAL进程每次在完成写事务日志的任务后，就会等待wal_writer_delay时间，然后将新产生的事务日志从缓冲区写到WAL文件中。准确的配置应该根据自身系统的运行状况。如果时间过长可能造成WAL buffer的内存不足，反之过小将会引起WAL的不断的写入，对磁盘的IO也是很大考验。PostgreSQL 9.5以后的pg_xlogdump都带有统计功能，可以查看不同类型的WAL记录的数量，大小以及FPI的比例。

3.1.5 wal_sync_method

字符串默认： wal_sync_method = fdatasync ，open_datasync、fdatasync(default on Linux)、fsync_writethrough、fsync、open_sync五选一   wal_sync_method:WAL写入磁盘的控制方式。一般采用默认值即可，对于裸设备或文件系统的可选配置，在实际的使用中所带来的方便相对fsync很有限。

3.1.6 synchronous_commit

字符串默认： synchronous_commit = on ，off、local、remote_write、remote_apply、on五选一       是否等待WAL完成后才返回给用户事务的状态信息。默认值是ON，表明必须等待WAL完成后才返回事务状态信息。配置OFF值能够更快的反馈回事务状态。因参数只是控制事务的状态反馈，因此对于数据的一致性不存在风险。但事务的状态信息影响着数据库的整个状态。该参数可以灵活的配置，对于业务没有严谨要求的事务可以配置为OFF，能够为系统的性能带来不小的提升。如果磁盘的IOPS一般，建议使用异步提交来提高性能，但是数据库crash或操作系统crash时，最多可能丢失2*wal_writer_delay时间段产生的事务日志（在wal buffer中） 

3.1.7 full_page_writes

布尔型默认： full_page_writes = on ，off、on二选一 重启数据库生效为on可以提高数据库的可靠性，减少数据丢失的概率，但是会产生过多的事务日志，降低数据库的性能。即服务器在checkpoint之后在对页面的第一次写时将整个页面写到wal里面。postgresql中数据处理过程中的位置只有内存和WAL中，在内存中的整个page中己包含更新提交的也包含没有提交的，如果不将整个page写入WAL中，在介质恢复时WAL中记录数据不足以实现完整的恢复(说白了就是无法实现介质恢复时事务的回滚),写入整个page。postgresql将前滚和回滚所需的数据都写入到了WAL。不管是否写入整个page，对数据库的PITR不影响(文档也说明了)，因为更新提交肯定要写入了WAL中。支持原子写超过BLOCK_SIZE的块设备，在对齐后可以关闭。或者支持cow的文件系统可以关闭。

3.1.8 wal_compression

布尔型默认： wal_compression = offenable compression of full-page writes如果是checkpoint后第一次修改页面，则输出整个page的内容(即full page image，简称FPI)。是否对full-page writes数据进行压缩（即去掉page中没有数据的hole部分）写入。 

3.1.9 commit_delay

数字型默认： commit_delay = 0 ，取值范围0-100000, 单位ms事务提交后，日志写到wal log上到wal_buffer写入到磁盘的时间间隔。减少IO，提高性能它设定事务在发出提交命令以后的睡眠时间，只有在睡眠了commit_delay指定的时间以后，事务产生的事务日志才会被写到事务日志文件中，事务才能真正地提交。增大这个参数会增加用户的等待时间，但是可以让多个事务被同时提交，提高系统的性能。如果数据库中的负载比较高，而且大部分事务都是更新类型的事务，可以考虑增大这个参数的值。0表示无延迟。即向WAL缓冲区写入记录和将缓冲区刷新到磁盘上之间的时间延迟。

3.1.10 commit_siblings

数字型默认： commit_siblings = 5  ，取值范围0-100000决定参数commit_delay是否生效。假设commit_siblings的值是5，如果数据库中正在执行的事务的个数大于或等于5，那么该事务将睡眠commit_delay指定的时间。如果数据库中正在执行的事务的个数小于5，这个事务将直接提交。

3.1.11 其他

wal_writer_flush_after = 1MB  # IO很好的机器，不需要考虑平滑调度, 否则建议128~256kBwal_log_hints = off                    # also do full page writes of non-critical updates

3.2 检查点 Checkpoints

3.2.1 checkpoint_timeout

数字型默认： checkpoint_timeout = 5min ，取值范围30s-1h重启数据库生效数据库进行检查点操作的间隔。如果现在的时间减去上次检查点操作结束的时间超过了checkpoint_timeout的值，系统就会自动启动一个检查点操作。不建议频繁做检查点，否则XLOG会产生很多的FULL PAGE WRITE(when full_page_writes=on)，导致数据库崩溃以后需要较长时间恢复操作。

3.2.2 checkpoint_completion_target

浮点数默认： checkpoint_completion_target = 0.5 ，取值范围0.0-1.0控制检查点操作的执行时间。硬盘好的情况下，可以让检查点快速结束，恢复时也可以快速达到一致状态。不要轻易地改变这个参数的值，使用默认值即可。只能在postgresql.conf文件中被设置。

3.2.3 其他

max_wal_size = 1GB # 建议是SHARED BUFFER的2倍min_wal_size = 80MB # 建议是max_wal_size/4checkpoint_flush_after = 256kB         # measured in pages, 0 disables IO很好的机器，不需要考虑平滑调度, 否则建议128~256kBcheckpoint_warning = 30s               # 0 disables

3.3 归档 Archiving

3.3.1 archive_mode

布尔值默认： archive_mode = off ，on和off二选一重启数据库生效对数据库进行周期备份，来防止数据的丢失，这就需要连续归档。它不仅可以用于大型数据库的增量备份和恢复，也可以用于搭建standby镜像备份。开启归档模式，主要涉及到三个参数：wal_level,archive_mode和archive_commandwal_level参数默认为mininal,设置此参数为archive或者之上的级别都可以打开归档。

3.3.2 archive_command

字符串默认： archive_command = ''  ， 占位符: %p=文件归档路径；%f=仅为文件名重启数据库生效当postgresql需要传输归档日志时，会调用archive_command指定的shell命令。归档文件传输成功时，shell命令要返回0，此时，postgresql会认为归档文件已经传输成功，因此可以删除或者重新循环利用归档文件。当shell命令返回非0值时，postgresql会保留所有未成功传输的归档日志，并不断尝试重新传输，直到成功。如果归档命令一直不成功，pg_xlog目录会持续增长，有耗尽服务器存储空间的可能，此时postgresql会PANIC关闭，直到释放存储空间。另外将归档WAL日志存储在本机上是风险极高，不被推荐的。postgresql通过archive_command提供了存储WAL日志的灵活性，可以将归档日志存储到挂装的NFS目录，磁带，刻录到光盘，也可以将WAL日志通过ssh/scp，rsync传输到异机保存。 

3.3.3 archive_dir

字符串默认： 在10版本的配置文件中找不到该配置重启数据库生效这个参数只有在启动数据库时，才能被设置。默认值是空串。它设定存放归档事务日志文件的目录。

3.3.4 archive_timeout

字符串默认： archive_timeout = 0 ， 单位是秒。0表示禁止重启数据库生效一般情况下，数据库只有在一个事务日志文件写满以后，才会切换到下一个事务日志文件。让数据库在一个事务日志文件尚未写满的情况下切换到下一个事务日志文件。值不是0，而且当前时间减去数据库上次进行事务日志文件切换的时间大于archive_timeout的值，数据库将进行一次事务日志文件切换。