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

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

 

1. 参数设置

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

synchronous_commit值	复制模式	说明
on	同步	先本地WAL记录刷盘并更新clog，等待收到同步slave写入WAL记录并刷盘成功的反馈后，才向会话返回事务成功。
remote_write	同步	先本地WAL记录刷盘并更新clog，等待收到同步slave写入WAL记录到磁盘的反馈后，才向会话返回事务成功。
local	异步	本地WAL记录刷盘并更新clog后，向会话返回事务成功。
off	异步	把WAL记录写到WAL缓存后，就返回事务成功。WAL记录的写盘和刷盘由wal writer进程在后台处理。

注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)

 

测试数据

架构	synchronous_commit值	tps	备注
单机	on	2481
	off	3939
1主2从	on	1052	有一段时间一度降到307，应该和网络不稳定有关
	remote_write	1711	有一段时间一度降到358，应该和网络不稳定有关
	local	2447
	off	3774

 

3.结论

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