New replication mode: async, write, fsync, replay-白红宇

PostgreSQL 9.1的同步复制事务需要等待同步复制节点的 xlog flush ACK 才可以结束事务（即等待xlog写入磁盘）。

而异步复制事务不需要standby的ACK。

在2012-01的commitFest中有一个关于新的复制模式的主题, 目前已经处于commited状态。

这个patch允许在standby节点的recovery.conf配置文件，加入了1个replication_mode参数，可选的参数值为，async, write, fsync, replay.

1. async

顾名思义代表这个standby是异步standby。

2. write

代表primary节点需要等待standby节点将接收到的xlog写入内存。

3. fsync

代表primary节点需要等待standby节点将接收到的xlog写入磁盘。

4. replay

代表primary节点需要等待standby节点将接收到的xlog完成恢复。

在write, fsync, replay模式下面，standby增加了一个XLogRecPtr消息，分别用来发送当前已经写入内存，磁盘，或完成恢复的location。

只有当primary接收到的XLogRecPtr中的location大于主节点正在等待的COMMIT location时，才可返回success给客户端。

还记不记得9.1的同步复制同一时刻只支持一台节点成为sync standby节点，其他的都是异步复制节点。

所以又有一个patch是关于quorum的。

在主节点的postgresql.conf参数中增加了一个quorum参数，默认等于0。记录的是需要收到ACK的STANDBY节点个数。

当系统中存在多个sync standby节点时，主节点必须接收到大于或等于quorum配置的个数个sync standby节点的replication ACK，事务才可返回给客户端success消息。

quorum个数大于当前系统中sync standby个数时以sync standby个数为准。

系统中没有sync standby节点但是配置的quorum>0时不受影响。

【小结】

1. 由于write模式返回的是xlog写入内存的位置，比flush到磁盘快很多，因此带来同步复制的性能增强，当然也带来了少许风险，如主节点和sync standby节点同时DOWN机是有风险的。

性能提升如下 :

synchronous_commit = on

tps = 424.510843 (including connections establishing)

tps = 420.767883 (including connections establishing)

tps = 419.715658 (including connections establishing)

tps = 428.810001 (including connections establishing)

tps = 337.341445 (including connections establishing)

synchronous_commit = write

tps = 550.752712 (including connections establishing)

tps = 407.104036 (including connections establishing)

tps = 455.576190 (including connections establishing)

tps = 453.548672 (including connections establishing)

tps = 555.171325 (including connections establishing)

2. quorum 参数降低了上面提到的风险问题，因为可以允许多个同步复制standby节点。

【参考】