PostgreSQL的流复制按是否等待slave的反馈分为同步流复制和异步流复制。理所当然，等待slave反馈的就是同步流复制，可以保障在主宕机的情况下安全的切到备机而不发生数据丢失。根据环境和流复制的同步方式的不同，性能可能会有很大差异。
1. 参数设置
如果要配置成同步流复制，synchronous_standby_names 必须设置为非空值。它指的是处于同步复制模式的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进行分析，进一步可以知道：
- slave上，”wal receiver process“负责接受，写入WAL记录并刷盘。同步模式下每次事务提交写入WAL和刷盘；异步模式下，可能会合并多个事务，刷一次盘。
- 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可以很大程度上减少性能损失，是一个比较实用的选择。另外，网络抖动是个非常讨厌的问题。以上同步异步的性能差异仅供参考，因为不同的布署环境下可能相差很大。
