Postgres的流复制

分类: ARCHITECTURE 发布于:

流复制起源

PostgreSQL 自从2010年推出的9.0版本开始，支持流式物理复制，用户可以通过流式复制，构建只读备库(主备物理复制，块级别一致)。流式物理复制可以做到极低的延迟（通常在1毫秒以内）。

同步流复制

2011年推出的9.1版本，支持同步复制，当时只支持一个同步流复制备节点（例如配置了3个备，只有一个是同步模式的，其他都是异步模式）。

在同步复制模式下，当用户提交事务时，需要等待这笔事务的WAL日志复制到同步流复制备节点，才会返回提交成功的ACK给客户端。

同步模式下，可以确保数据的0丢失。（只要客户端收到了事务提交成功的ACK，这笔事务的WAL就有两份。）

级联流复制

2012年推出的9.2版本，支持级联流复制。意思是备库还可以再连备库。

级联复制特别适合跨机房的使用，例如主库在A机房，备库在B机房，但是B机房需要建立多个备库时，那么B机房只需要建立一个直连主库的备库，其他的备库可以通过B机房的这个备库级联产生。从而减少网络开销。

流式虚拟备库

2012年推出的9.2版本，除了支持级联复制，还支持虚拟备库，什么是虚拟备库呢？就是只有WAL，没有数据文件的备库。

通过虚拟备库，可以流式的接收WAL，进行实时的流式WAL归档。提高备份或归档的实时性。

逻辑复制的基础

2014年推出的9.4版本，在WAL中增加了逻辑复制需要的基础信息，通过插件，可以实现逻辑复制。

逻辑复制可以做到对主库的部分复制，例如表级复制，而不是整个集群的块级一致复制。

逻辑复制的备库不仅仅是只读的，也可以执行写操作。

增加几种同步级别

2016年推出的9.6版本，PG的流式复制，通过复制WAL达到同步的目的，因此同步级别也和WAL有关。通过synchronous_commit参数，可以配置事务的同步级别。

1、on, 表示本地WAL fsync，同步standby WAL fsync。即两份持久化的WAL。

2、remote_apply, 表示本地WAL fsync，同步standby WAL 已恢复。这个带来的RT最高。

3、remote_write, 表示本地WAL fsync，同步standby WAL 异步write完成。一份持久化，备库的WAL可能还在OS CACHE中。

4、local, 表示本地WAL fsync。

5、off, 表示本地WAL写到wal buffer中即返回客户端事务提交成功的ACK，为异步提交（数据库CRASH可能导致事务丢失，但不会导致数据库不一致）。

RT影响，从低到高如下：

off, local, remote_write, on, remote_apply。