PostgreSQL复制中有个很重要的参数：synchronous＿commit。它决定何时向客户端确认事务提交成功。这个参数不仅仅关于主备同步，还有更广泛的含义，对于单机PG实例也很有用。为了更好地理解，需要了解WAL记录的整个传播过程以及可以接受提交确认的各个阶段。这使得我们能够为每个事务选择不同级别的持久性。持久性的级别越低，确认越快，从而提高系统整体吞吐量和性能。

WAL传播

首先看下WAL传播过程。

PG内部函数pg＿write（）将WAL日志写入WAL段文件内，内部使用write（）系统调用，并不保证数据刷写到磁盘。为了完成刷写，需要调用issue＿xlog＿fsync（），根据GUC参数wal＿sync＿method发出适当类型的fsync：

上图显示了所有的5个阶段：

1）WAL记录插入本地WAL BUFFER：WAL记录首先在WAL缓冲区中创建。由于多个后台进程将并发创建WAL，因此需要锁来包含。不同的后台进程将WAL BUFFER中的WAL持续写入WAL段文件。如果sychronous＿commit设置为off，则不会立即刷写，而是依赖于wal＿writer＿delay的设置。

2）WAL write和WAL flush。对本地磁盘上的WAL段文件进行刷写是一个繁重的操作之一。PG在这方面做了很多优化，以避免频繁刷写。

3）远程写入。WAL记录写入远程操作系统缓存，但并没有刷新。数据可能会在操作系统缓存保留一段时间。除非需要解决主备同时崩溃的情况，否则可以考虑使用这种级别的持久性保护。

4）远程刷新。这个阶段，数据才真正写入远程备机的磁盘。所以此时崩溃也可以保证备机的数据是可用的。

5）远程应用。这个阶段，WAL记录在远程备机回放，并且正在运行的会话可以访问。

这样再看该参数的可用值意义：

1）off：关闭synchronous＿commit可以使用off，0，false或者no。顾名思义，提交确认可以在将记录刷新到磁盘之前进行。通常称为异步提交。如果PG崩溃，最后几个异步提交可能会丢失。

2）local：WAL记录写入并刷写到本地磁盘。这种情况下，将本地WAL日志写入和刷写完成后才提交。

3）remote＿write：WAL记录成功发送给备机，远程备机确认写入（不是刷写）

4）on：这个是默认值。可以使用on，true，yes或者1．根据是否有复制含义可能有所不同。若有复制，则导致等等“远程刷新”

5）remote＿apply：直到备机接收到的事务回放了，才返回主机确认可以提交了。

如果没有同步备机synchronous＿standby＿names为空，则synchronous＿commit：on、remote＿apply、remote＿write和local的设置都提供相同级别的同步级别：事务提交只等待本地刷新到磁盘。不同值对性能的影响：

off （async） ＞ on （async） ＞ remote＿write （sync） ＞ on｜local （sync）  ＞ remote＿apply （sync）

那么当选择完全异步提交synchronous＿commit＝off时，会丢失多少数据呢？

这依赖于wal＿writer＿delay的设置。默认是200ms。也就是每隔wal＿writer＿delay，WAL writer都会被唤醒并调用XLogBackgroundFlush（），将WAL刷写到磁盘。他会检查完全填充的WAL页，如果可用，则将WAL write到这个点。在良好负载下，WAL writer会将整个WAL BUFFER都write。在没有找到full pages的低负载情况下，仅刷写到上一个异步提交的位置。

如果超过wal＿writer＿delay或者自上次刷新以来写入的块超过wal＿writer＿flush＿after，则WAL 被刷新到当前位置。这种安排保证了异步提交记录在事务完成后最多两次wal＿writer＿delay后到达磁盘。但是，PostgreSQL 以灵活的方式写入／刷新完整缓冲区，这是为了减少在每个 WAL writer周期填充多个 WAL 页面时在高负载下发出的写入次数。从概念上讲，这使得最坏情况延迟最多三个wal＿writer＿delay 周期。

在大多数情况下，损失将小于 wal＿writer＿delay 的两倍。但在最坏的情况下，它可能高达三倍。