Postgrsql专栏（8）Write Ahead Log相关配置

1、wal_level
wal_level决定写入WAL的信息量。默认值是minimal，只写入从崩溃中恢复或立即关闭所需的信息。archive 添加了WAL归档所需的日志记录; hot_standby进一步增加了在备用服务器上运行只读查询所需的信息;最后logical添加了支持逻辑解码所需的信息。每个级别都包含记录在所有较低级别的信息。该参数只能在服务器启动时设置。

如果设置为minimal ，可以安全地跳过一些批量操作的WAL记录，这可以使这些操作更快。可以应用此优化的操作包括：
CREATE TABLE AS
创建索引
簇

复制到在同一事务中创建或截断的表中但minimal的WAL不包含足够的信息来重建基本备份和WAL日志中的数据，因此必须使用归档或更高级别来启用WAL归档（archive_mode）和流式复制。

在hot_standby级别，将记录与归档相同的信息，以及重建WAL中正在运行的事务状态所需的信息。要在备用服务器上启用只读查询，必须在主服务器上将wal_level设置为hot_standby或更高（主从），并且必须在备用服务器中启用hot_standby。据认为，在使用hot_standby和存档级别之间，性能之间几乎没有可衡量的差异，因此，如果对生产的影响很明显，欢迎提供反馈意见。

在逻辑级别中，记录的信息与hot_standby相同，还包括允许从WAL中提取逻辑变更集所需的信息。使用逻辑级别会增加WAL卷的数量，特别是如果为REPLICA IDENTITY FULL配置了许多表并且执行了许多UPDATE和DELETE语句。

2、fsync
如果打开这个参数，PostgreSQL服务器将尝试通过发出fsync（）系统调用或各种等效方法（请参阅wal_sync_method）来确保更新物理写入磁盘。这确保了在操作系统或硬件崩溃后数据库集群可以恢复到一致状态。

虽然关闭fsync通常会带来性能上的好处，但如果发生电源故障或系统崩溃，这可能会导致不可恢复的数据损坏。因此，如果您可以轻松地从外部数据重新创建整个数据库，仅建议关闭fsync。

关闭fsync的安全环境示例包括：从备份文件初始加载新数据库集群，使用数据库集群处理一批数据，之后数据库将被丢弃并重新创建，或用于只读数据库克隆经常重新创建，不用于故障转移。高质量的硬件本身并不足以成为关闭fsync的理由。

为了在将fsync从off更改时进行可靠恢复，必须强制内核中的所有已修改缓冲区进行持久存储。这可以通过运行initdb –sync-only，运行同步，卸载文件系统或重新启动服务器来关闭群集或fsync打开时完成。

在很多情况下，关闭用于非关键事务的synchronous_commit可以提供关闭fsync的许多潜在性能优势，而没有数据损坏的伴随风险。

fsync只能在postgresql.conf文件或服务器命令行中设置。如果您关闭此参数，请考虑关闭full_page_writes。

3、synchronous_commit
指定在命令向客户端返回“成功”指示之前，事务提交是否将等待WAL记录写入磁盘。有效值为on，remote_write，local和off。默认和安全设置已打开。当关闭时，从向客户报告成功的时间到确保事务确实对服务器崩溃安全的时间之间可能存在延迟。 （最大延迟是wal_writer_delay的三倍）。与fsync不同，将此参数设置为off不会造成数据库不一致的风险：操作系统或数据库崩溃可能导致某些最近涉嫌提交的事务丢失，但数据库状态将会就好像这些交易已被彻底放弃一样。因此，关闭transaction_commit可能是一个有用的选择，当性能比事务的持久性确切的确定性更重要时。有关更多讨论，请参见第29.3节。

如果设置了synchronous_standby_names，则此参数还控制事务提交是否将等待事务的WAL记录被复制到备用服务器。设置为on时，提交将等待，直到来自当前同步备用数据库的回复表明它已收到事务的提交记录并将其刷新到磁盘。这确保了事务不会丢失，除非主服务器和备用服务器都遭受数据库存储的损坏。当设置为remote_write时，提交将等待，直到来自当前同步备用数据库的回复表明它已收到事务的提交记录并将其写入备用数据库的操作系统，但数据未必达到备用数据库上的稳定存储。即使PostgreSQL的备用实例崩溃，此设置也足以确保数据保留，但如果备用服务器遭受操作系统级别的崩溃，则无法保留该设置。

在使用同步复制时，通常会等待同时等待本地刷新到磁盘和复制WAL记录，或允许异步提交事务。但是，本地设置可用于希望等待本地刷新到磁盘的事务，但不能同步复制。如果未设置synchronous_standby_names，则remote_write和local all上的设置将提供相同的同步级别：事务提交仅等待本地刷新到磁盘。

该参数可以随时更改;任何一项交易的行为是由提交时有效的设置决定的。因此，有可能并且有用的是，一些事务同步地提交，而另一些异步地异步提交。例如，当默认值是相反时，为了使单个多条件事务异步提交，请在事务中发出SET LOCAL synchronous_commit TO OFF。

4、wal_sync_method
用于强制WAL更新到磁盘的方法。如果fsync关闭，则此设置无关紧要，因为WAL文件更新根本不会被强制排除。可能的值是：
open_datasync（使用open（）选项写入WAL文件O_DSYNC）
fdatasync（每次提交时调用fdatasync（））
fsync（在每次提交时调用fsync（））
fsync_writethrough（在每次提交时调用fsync（），强制直写任何磁盘写入缓存）
open_sync（使用open（）选项写入WAL文件O_SYNC）
如果可用，open_ *选项也使用O_DIRECT。并非所有这些选择都可用于所有平台。默认值是平台支持的上述列表中的第一种方法，但fdatasync是Linux上的默认值。默认不一定是理想的;可能需要更改此设置或系统配置的其他方面，以便创建防撞保护配置或实现最佳性能。这些方面在第29.1节中讨论。该参数只能在postgresql.conf文件或服务器命令行中设置。

Archiving相关配置
1、archive_mode
当启用archive_mode时，通过设置archive_command将完成的WAL段发送到归档存储。 除关闭外，要禁用，还有两种模式：开启和始终。 在正常操作期间，两种模式之间没有区别，但设置为始终在存档恢复或待机模式下也启用WAL存档器。 在始终模式下，从归档还原或流式复制流式传输的所有文件都将被归档（再次）。
archive_mode和archive_command是单独的变量，因此可以在不离开存档模式的情况下更改archive_command。 该参数只能在服务器启动时设置。 当wal_level设置为minimal时，无法启用archive_mode。

2、archive_command
执行本地shell命令以归档已完成的WAL文件段。字符串中的任何％p被替换为要归档的文件的路径名称，并且任何％f都将仅替换为文件名。 （路径名相对于服务器的工作目录，即集群的数据目录。）使用%%在命令中嵌入实际的％字符。只有成功时，该命令才能返回零退出状态，这一点很重要。

该参数只能在postgresql.conf文件或服务器命令行中设置。除非在服务器启动时启用了archive_mode，否则将被忽略。如果在启用archive_mode的情况下archive_command是空字符串（缺省值），则暂时禁用WAL归档，但服务器会继续累积WAL段文件，以期即将提供命令。将archive_command设置为一个只返回true的命令，例如/ bin / true（Windows中的REM）可以有效地禁用归档，但也会打破归档恢复所需的WAL文件链，因此只能在特殊情况下使用。

3、archive_timeout
archive_command仅为已完成的WAL段调用。因此，如果您的服务器生成很少的WAL流量（或者在这种情况下存在冗余时段），则在事务完成和归档存储器中的安全记录之间可能存在很长的延迟。为了限制未归档的数据的存储时间，可以设置archive_timeout来强制服务器定期切换到新的WAL段文件。当此参数大于零时，只要从最后一个段文件切换后经过了许多秒，服务器就会切换到新的段文件，并且存在任何数据库活动（包括单个检查点）。 （增加checkpoint_timeout将减少空闲系统上不必要的检查点。）请注意，由于强制切换而提前关闭的归档文件的长度与完整文件的长度相同。因此，使用非常短的archive_timeout是不明智的 - 它会使您的归档存储膨胀。一分钟左右的archive_timeout设置通常是合理的。如果您希望将数据从主服务器上快速复制出来，则应考虑使用流式复制而不是归档。该参数只能在postgresql.conf文件或服务器命令行中设置。

详细文档请参考：
https://www.postgresql.org/docs/9.5/static/runtime-config-wal.html