Vast+产品展厅 | Vastbase流复制，为备份加速

数据备份是企业稳健发展的基础，通过流复制的方式可以快速将主库的数据同步到备库上，极大的缩短备份时间，保障数据备份的实时性和业务的连续性。

本期Vast+产品展厅，为您介绍Vasebase流复制的整体设计框架和实现原理。

在未引入流复制功能之前，主备之间的同步只能以xlog文件为粒度。主库将一个xlog文件写满并切换到下一个xlog文件之后，才能将之前的xlog文件传输到备库进行回放，这使得主备之间存在极大的延迟。

引入流复制功能后，粒度转变为xlog记录，每当主库完成xlog的落盘，都会被及时的传输到备库进行回放，这不仅降低了主备之间的延迟，而且使得同步流复制成为可能。

Vastbase流复制主要涉及三类线程的协作：

主库的WalSender线程：发送xlog日志

备库的WalReceiver线程：接收xlog日志

备库的Startup线程：回放xlog日志

串行回放模式下由Startup线程进行回放，并行回放和极致RTO还存在其它辅助线程，本文以串行回放为例。

原理如图所示：

2.1

流复制的主要步骤

1

主库后端线程处理写请求时，写xlog到缓冲区（WalBuffer）

2

主库缓冲区中的xlog会在适当的时机落盘（同步事务提交、WalWriter等）并唤醒WalSender线程

3

主库WalSender线程从磁盘上读取还未发送的xlog到内存，并发送给备库的WalReceiver线程

4

备库的WalReceiver线程将收到的xlog写入磁盘（通知WalRcvWriter线程进行写入）并唤醒Startup线程进行回放

5

备库的Startup线程从磁盘读取xlog并回放

2.1

流复制的启动流程

1

启动主库（启动参数-M primary）

2

启动备库（启动参数-M standby）

3

备库启动Startup线程回放本地的xlog

4

备库Startup线程回放完本地的xlog

5

备库Startup线程设置流复制起点、主库连接信息、复制槽名称等信息，并通知Postmaster线程启动WalReceiver线程

6

备库Postmaster线程启动Walreceiver线程

7

备库WalReceiver线程连接主库，流复制连接的连接信息中replication=true

8

主库Postmaster线程根据replication=true判断是流复制连接，启动WalSender线程

9

主库WalSender线程与备库WalReceiver线程握手阶段，包括数据库版本校验、运行角色校验（是否以主库模式运行）、system identifier校验（是否来自同一实例）、xlog一致性校验等

10

进入流复制阶段，若备库xlog落后过多可能还存在追赶阶段

2.3

同步流复制

引入流复制功能之后，可以配置更加丰富的同步级别，其中关键的guc参数如下：

1.    synchronous_standby_names

2.    synchronous_commit

3.    most_available_sync

*具体含义参考官方文档

开启同步流复制后，主库事务的提交需等待相应备库接收、写入、落盘或回放到对应xlog位置后才能向客户端返回成功，相关流程如下图所示：

备库的WalReceiver线程会告知主库的WalSender线程当前xlog的接收、写入、落盘以及回放的位置，当其超过某个事务提交时产生的最后一条xlog日志的位置时，主库的WalSender线程便可以将对应的后端线程唤醒，反馈给客户端。

由于不同事务的synchronous_commit级别可以不同，Vastbase使用四个队列来保存需要等待唤醒的后端线程信息。事务在提交阶段根据自身的级别选择对应的队列，WalSender线程在收到WalReceiver反馈的xlog回放位置信息后，判断是否需要唤醒相关队列中的线程。另外，每个队列都是按等待的xlog位置排序的，从而能够提高唤醒的效率。如下图所示：

2.4

复制槽

由于主库的xlog日志不会一直保存，在做checkpoint的时候可能会清理不再需要的xlog，若备库还未收到这些xlog，那么流复制便会中断。Vastbase的复制槽机制可以解决这个问题，通过创建复制槽，阻止备库还未收到的xlog被主库清理。同时，也需预防因复制槽导致的xlog堆积，通过pg_replication_slots视图可查看复制槽的状态。

通过Vastbase流复制功能加快了主备同步、降低了主备延迟，为备份加速提速。

还可以灵活配置不同的同步级别，满足用户对数据持久性的不同要求。