11.1 流复制的启动_PostgreSQL技术内幕

在流复制中，有三种进程协同工作。首先，主库上的walsender（WAL发送器）进程将WAL数据发送到备库；同时，备库上的walreceiver（WAL接收器）在接收这些数据，而备库上的startup进程可以重放这些数据。其中walsender和walreceiver 之间使用单条TCP连接进行通信。

在本节中，我们将探讨流复制的启动顺序，以了解这些进程如何启动并且它们之间是如何建立连接的。图11.1显示了流复制的启动顺序图：

图11.1 流复制的启动顺序

启动主库服务器和备库服务器。
备库服务器启动一个startup 进程。
备库服务器启动一个walreceiver 进程。
walreceiver 向主库服务器发送连接请求。如果主库尚未启动，walreceiver 会定期重发该请求。
当主库服务器收到连接请求时，将启动walsender 进程，并建立walsender 和walreceiver 之间的TCP连接。
walreceiver 发送备库数据库集簇上最新的LSN。在IT领域中通常将该阶段称作握手（handshaking） 。
如果备库最新的LSN小于主库最新的LSN（备库的LSN < 主库的LSN），则walsender 会将前一个LSN到后一个LSN之间的WAL数据发送到walreceiver 。这些WAL数据由存储在主库pg_xlog子目录（版本号为10+的更名为pg_wal）中的WAL段提供。最终，备库重放接收到的WAL数据。在这一阶段，备库在追赶主库，因此被称为追赶（catch-up） 阶段。
最终，流复制开始工作。

每个walsender 进程都维护了连接上的walreceiver 或其他应用程序的复制进度状态 （请注意，不是连接到walsender 的walreceiver 或应用程序的本身的状态）。如下是其可能的状态：

启动（start-up） —— 从启动walsender 到握手结束。如图11.1(5)-(6)。
追赶（catch-up） —— 处于追赶期间，如图11.1(7)。
流复制（streaming） —— 正在运行流复制。如图11.1(8)。
备份（backup） —— 处于向pg_basebackup等备份工具发送整个数据库集簇文件的过程中。

系统视图pg_stat_replication显示了所有正在运行的walsenders 的状态，如下例所示：

testdb=# SELECT application_name,state FROM pg_stat_replication;
 application_name |   state
------------------+-----------
 standby1         | streaming
 standby2         | streaming
 pg_basebackup    | backup
(3 rows)

如上结果所示，有两个walsender 正在运行，其正在向连接的备库发送WAL数据，另一个walsender 在向pg_basebackup应用发送所有数据库集簇中的文件。

在备库长时间停机后，如果重启会发生什么？

在9.3版及更早版本中，如果备库所需的WAL段在主库上已经被回收了，备库就无法追上主库了。这一问题并没有可靠的解决方案，只能为参数wal_keep_segments配置一个较大的值，以减少这种情况发生的可能性，但这只是权宜之计。

在9.4及后续版本中，可以使用复制槽（replications slot） 来预防此问题发生。复制槽是一项提高WAL数据发送灵活性的功能。主要是为逻辑复制（logical replication） 而提出的，同时也能解决这类问题 ——复制槽通过暂停回收过程，从而保留pg_xlog（10及后续版本的pg_wal）中含有未发送数据的的WAL段文件，详情请参阅官方文档。

下一节：流复制有两个方面：日志传输和数据库同步。因为流复制基于日志，日志传送显然是其中的一个方面 —— 主库会在写入日志记录时，将WAL数据发送到连接的备库。同步复制中需要数据库同步 —— 主库与多个备库通信，从而同步整个数据库集簇。

为准确理解流复制的工作原理，我们应该探究下主库如何管理多个备库。为了尽可能简化问题，本节描述了一个特例（即单主单备系统），而下一节将描述一般情况（单主多备系统）。