PostgreSQL流复制的几种不同参数设置及性能实测对比

PostgreSQL的流复制按是否等待slave的反馈分为同步流复制和异步流复制。理所当然，等待slave反馈的就是同步流复制，可以保障在主宕机的情况下安全的切到备机而不发生数据丢失。根据环境和流复制的同步方式的不同，性能可能会有很大差异。

1. 参数设置

如果要配置成同步流复制， 必须设置为非空值。它指的是处于同步复制模式的slave的application_name。可以设置多个，用逗号分隔；也可以干脆设置成‘*’，代表任意slave。除此以外，同步还是异步就受synchronous_commit参数控制了，不同的设置代表了不同的性能和可靠性的权衡。具体如

注1:执行每个更新语句时会写入WAL记录，并通知wal sender进程发送WAL到slave。（不像MySQL，MySQL在提交阶段才发送binlog，无疑会增加master等待slave反馈的时间，对大事务问题更严重。）

注2:参考src/backend/access/transam/xact.c中的RecordTransactionCommit()函数

使用strace进行分析，进一步可以知道：

1. slave上，”wal receiver process“负责接受，写入WAL记录并刷盘。同步模式下每次事务提交写入WAL和刷盘；异步模式下，可能会合并多个事务，刷一次盘。
2. master上，synchronous_commit=off时，"wal writer process"负责定期写WAL页(每次8K)和刷盘；其它情况下"postgres"会话进程负责在执行每个事务时写本地wal记录并刷盘。

strace -ewrite,lseek,fdatasync -T -tt -p
复制

2.性能对比

下面晒一下我的4核虚机环境下，不同synchronous_commit设置的性能数据。

测试方法

通过pgbench在scale为10的场景下，跑TPC-B测试。

[postgres@srdsdevapp73 ~]$ pgbench -n -h 10.27.177.246 -c 16 -j 4 -T 5 transaction type: TPC-B (sort of) scaling factor: 10 query mode: simple number of clients: 16 number of threads: 4 duration: 5 s number of transactions actually processed: 18581 latency average: 4.305 ms tps = 3710.162082 (including connections establishing) tps = 3720.628664 (excluding connections establishing)
复制

测试数据

3.结论

同步复制导致的性能损失还是比较大的，使用remote_write而不是on可以很大程度上减少性能损失，是一个比较实用的选择。另外，网络抖动是个非常讨厌的问题。以上同步异步的性能差异仅供参考，因为不同的布署环境下可能相差很大。