postgresql流复制发展技术时间线

在PostgreSQL9.0之前，是基于文件（base-file）的传输方式，其传输WAL日志的方法是主库写完一个完整的WAL日志之后，再把WAL日志文件拷贝到备库，然后备库再应用该WAL文件，当然了，备库也只能作为备份的存在，因为它不支持读写。且由于不是实时同步，势必导致高延迟的主备延迟。

在9.0版本之后引入了流复制方法，通过流复制，备库不断的从主库同步相应的数据，并在备库应用每个WAL record，每次传输单位是WAL日志的record。同时PostgreSQL9.0之后提供了Hot Standby，能够实现和oracle 11g出现的active dataguard一样的功能，备库在接收并应用WAL日志的同时也能够为用户提供只读服务，实现读写分离，提升了用户体验。

流复制的发展在每个版本都有不同程度的迭代和更新，逐步成长为一个功能丰富、使用方便的高可用架构。从9.0版本开始到现在，流复制的应运而生，伴随着时间发展延续，其灵活性和稳定性从一定程度上打响了PostgreSQL在数据库浪潮中占得一席之地的重要一枪。

流复制的原理

流复制模式的工作原理，通过前面的阐述，我们已经了解到流复制就是通过将主库产生的WAL日志，不断地传输到备库，然后备库应用WAL来实现对原数据的更改确保一致性的过程，那么主备库中各进程具体是怎么协同操作的呢？

从图示中我们可以很清楚的看到，PostgreSQL服务器的后台进程在事务commit之后，一边准备将脏数据刷入磁盘上的数据文件中，一边通过walbuffer将操作记录写入wal日志，然后主库通过walsender进程将wal日志传输给备库，备库walreceiver进程接收，使用walwrite进程写入自己本地的wal日志中，最后通过startup进程应用到数据文件上，实现备库与主库数据的一致性。

PostgreSQL流复制架构拥有异步和同步模式，在同步流复制模式中我们通过控制主库的synchronous_commit参数来指定当数据库提交事务时是否需要等待WAL日志写入硬盘后才向客户端返回成功，它的可选值及对应作用如下表所示（摘录于官方文档）。

为了便于理解，我们用图示来具体表示设置不同的synchronous_commit等级所带来的影响。

主库提交事务的这一过程，参数的不同设置具体表现为以下情况：

当置为off的时候，不需等待本地相应WAL数据写入本地WAL日志文件即可向客户端返回成功。

当置为local的时候，需等待相应WAL数据写入本地WAL日志文件后才向客户端返回成功。

当置为remote_write的时候，需等待备库接收主库发送的WAL日志并写入备节点操作系统缓存中，才向客户端返回成功，此时只有主库才有一份已经落盘的wal文件。

当置为on的时候，需等待备库接收主库发送的WAL日志并写入WAL文件，之后才向客户端返回成功，这个时候备库和主库都有一份已经落盘的wal文件。

当置为remote_apply的时候，需等待备库完成对wal日志的应用才向客户端返回成功，那么这个等级所带来的的事务相应时间也是最长的。

我们对这五个参数的做一次性能比较，在同一环境下，对比这些不同值得设定对同步流复制性能的影响。

我们使用pgbench做性能测试，每个参数的设定值都测试三次取平均值，得出如下统计图表：

synchronous_commit 是支持事务级的参数，用户可以根据会话的级别来具体配置。从图表中我们可以看到synchronous_commit设置不同的值，对数据库性能是有一定程度影响的。

在实际操作中，我们需要根据环境的实际情况来选择同步或异步模式，同步模式需要等待备库的写盘才能返回成功，这样一来，在主备库复制正常的情况下，能够保证备库的数据不会丢失，但是带来的一个问题是，一旦备库down掉，主库就会挂起而无法进行后续的操作，也就是说，在同步模式中，备库对主库的影响是很大的，而异步模式就不会发生这种情况。因此，在生产环境中，我们大多不会选择同步复制模式。