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

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可以很大程度上减少性能损失，是一个比较实用的选择。另外，网络抖动是个非常讨厌的问题。以上同步异步的性能差异仅供参考，因为不同的布署环境下可能相差很大。