第十一章 PostgreSQL中的流复制

一章 PostgreSQL中的流复制"/>

第十一章 PostgreSQL中的流复制

搞了一个公众号PostgreSQL运维技术，欢迎来踩~

悄悄放一张：

PostgreSQL运维技术 

原文：.html

 

同步流复制的特性是从9.1版本开始实现的，这种本地复制特性是基于log shipping，这是一种通用的复制技术。其中主服务器持续地发送wal数据，然后备库在本地对接收到的wal数据进行重放。

这一章文字比较多，也是PG实现高可用（一主多从）的基石，很重要......

 

这章包括以下几个主题：

流复制如何启动

数据如何在主和备之间传输

主服务器如何管理多个备用服务器

主服务器如何检测备用服务器的故障

 

 

11.1. 启动流复制

 

在流复制中，有三种流程协同工作。主服务器上的walsender进程向备服务器发送WAL数据;然后，一个walreceiver和一个启动进程在备用服务器上接收并回放这些数据。walsender和walreceiver使用单个TCP连接进行通信。

在本节中，我们将探索流复制的启动顺序，以理解这些进程是如何启动的，以及如何建立它们之间的连接。流复制的启动顺序图如图11.1所示:

图11.1 流复制启动的时序图

图片来源：

.html

 

(1)启动主备服务器。

(2)备用服务器启动startup 进程。

(3)备服务器启动walreceiver进程。

(4)walreceiver向主服务器发送连接请求。如果主服务器没有运行，walreceiver会定期发送这些请求。

(5)当主服务器接收到连接请求时，它启动walsender进程，并在walsender和walreceiver之间建立TCP连接。

(6) walreceiver发送standby数据库集群的最新LSN。一般来说，这个阶段在信息技术领域被称为握手。

(7)如果备节点的最新LSN小于主节点的最新LSN (standby's LSN < primary's LSN)，则walsender将发送最新LSN的WAL数据给备库。这些WAL数据由存储在主节点pg_xlog子目录(version 10或更高版本为pg_wal子目录)中的WAL段提供。然后，备用服务器回放接收到的WAL数据。在这个阶段中，备用程序会追赶主程序，因此称为追赶。

(8)流式复制开始工作。

 

每个walsender进程保持一个已连接的walreceiver或任何应用程序的工作阶段的状态(注意，它不是walreceiver或连接到walsender的应用程序的状态)。以下是它可能的状态:

start-up: 启动阶段。从启动walsender到握手结束。参见图11.1(5)-(6)。

catch-up: 追赶阶段。见图11.1(7)。

streaming: 流复制工作中。见图11.1(8)。

backup: 在为备份工具(如pg_basebackup程序)发送整个数据库集群的文件时。

pg_stat_replication视图显示所有正在运行的walsender的状态。示例如下:

 

考虑一个问题，如果备用服务器在长时间停止状态下重新启动会发生什么?

在9.3或更早的版本中，如果备用服务器所需要的主服务器的WAL段已经被回收，那么备用服务器将无法赶上主服务器。对于这个问题，没有可靠的解决方案，只能为配置参数wal_keep_segments设置一个较大的值，以减少发生这种情况的可能性。这是一个权宜之计。

在9.4或更高版本中，可以通过使用复制插槽来防止此问题。复制槽是一个功能,它扩展了WAL数据传送的灵活性。即当pg_xlog目录下wal文件包含还未传送到从库的数据(如果10或更高版本则是pg_wal目录)，则这部分的wal日志不会被回收。

 

11.2. 如何进行流复制

 

流复制有两个方面:日志传送和数据同步。日志传送显然是其中一个方面，因为流复制是基于它的——每当发生写操作时，主服务器将WAL数据发送到连接的备用服务器。

同时同步复制需要数据同步—主服务器与每个多备服务器通信，以同步其数据库集群。

为了准确理解流复制的工作原理，我们应该探究一个主服务器如何管理多个备用服务器。为了简单起见，本节将描述特殊情况(即单主单备系统)。

 

11.2.1. 主服务器和同步备用服务器之间的通信

 

假设备用服务器处于同步复制模式，但是禁用了配置参数hot-standby，并且wal_level为“archive”。主服务器的主要参数如下所示:

synchronous_standby_names = 'standby1'hot_standby = offwal_level = archive

 

此外，在第9.5节中提到的三个写入WAL数据的触发器中，我们在这里关注事务提交。

假设主服务器上的一个backend 进程以自动提交模式发出一条简单的INSERT语句。backend 启动事务，发出INSERT语句，然后立即提交事务。让我们进一步探索这个commit提交操作将如何完成。如图11.2所示:

 

图11.2. 流复制的通信时列图。

 

(1)backend进程通过执行函数XLogInsert()和XLogFlush()，将WAL数据写入和刷新到WAL段文件中。

(2) walsender进程将写入WAL段的WAL数据发送给walreceiver进程。

(3)backend进程发送完WAL数据后，继续等待备用服务器的ACK响应。更准确地说，backend进程通过执行内部函数SyncRepWaitForLSN()来获取锁存器，并等待锁存器被释放。

(4)备用服务器上的walreceiver通过write()系统调用将接收到的WAL数据写入备用服务器的WAL段，并返回一个ACK响应给walsender。

(5) walreceiver通过系统调用(如fsync())将WAL数据刷新到WAL段，然后返回另一个ACK响应给walsender，并将WAL数据的更新通知startup进程。

(6)startup进程回放已经写入WAL段的WAL数据。

(7) walsender在收到walreceiver的ACK响应后释放后端进程的锁存器，然后后端进程的提交或中止操作将完成。锁存器释放的时间取决于参数synchronous_commit。当它是'on'(默认)，当接收到第(5)步的ACK时锁存器被释放，当它是是'remote_write'，当接收到第(4)步的ACK时锁存器被释放。

如果配置参数wal_level是'hot_standby'或'logical'， PostgreSQL会在commit或abort操作的记录之后，写一条关于热备特性的WAL记录。(在这个例子中，PostgreSQL没有写这个记录，因为它是'archive'。)

 

每个ACK响应将备用服务器的内部信息通知主服务器。它包含下列四个信息:

最新written的WAL数据的LSN

最新flushed的WAL数据的LSN

最新applyed的WAL数据的LSN

发送响应时的时间戳

 

Walreceiver不仅在写入(write)和刷新(flush)WAL数据时返回ACK响应，且基于备用服务器的心跳机制，也会周期性地给主库返回ACK响应。因此，主服务器总是掌握所有连接的备用服务器的状态。

通过发出如下查询，可以显示连接的备用服务器的LSN相关信息：

postgres=# select sent_lsn,write_lsn,flush_lsn,replay_lsn from pg_stat_replication ;-[ RECORD 1 ]----------sent_lsn   | 1/2F000000write_lsn  | 1/2F000000flush_lsn  | 1/2F000000replay_lsn | 1/2F000000

心跳间隔设置为wal_receiver_status_interval参数，默认为10秒。

 

11.2.2. 故障发生时的行为

 

在本小节中，将描述同步备用服务器发生故障时主服务器的行为，以及如何处理这种情况。

如果同步备用服务器发生故障，不再能够返回ACK响应，主服务器将会永远等待响应。因此，无法提交正在运行的事务，也无法启动后续的查询处理。换句话说，所有主要服务器操作实际上都已停止。(流复制不支持通过超时自动恢复到异步模式的函数。)

有两种方法可以避免这种情况。

其中一种方法是使用多个备用服务器来提高系统可用性。

另一种方法将从同步模式切换到异步模式:

(1)设置参数synchronous_standby_names为空字符串。

synchronous_standby_names = ''

(2)执行带有reload选项的pg_ctl命令。

postgres> pg_ctl -D $PGDATA reload

 

11.3. 管理多个备用服务器

 

在本节中，将描述流复制与多个备用服务器一起工作的场景。

 

11.3.1. sync_priority and sync_state

 

主服务器为所有受管理的备用服务器提供sync_priority和sync_state，并根据每个备用服务器各自的值对待它们。(主服务器即使只管理一个备用服务器也会给出这些值;在前一节中没有提到这一点。)

sync_priority同步模式下备用服务器的优先级，为固定值。值越小表示优先级越高，而0是表示“异步模式”的特殊值。备用服务器的优先级按照主服务器的配置参数synchronous_standby_names中列出的顺序给出。例如，在下面的配置中，standby1的优先级为1,standby2的优先级为2。

synchronous_standby_names = 'standby1, standby2'

(此参数中没有列出的备用服务器处于异步模式，优先级为0。)

sync_state是备用服务器的状态。它根据所有备用服务器的运行状态和个人的优先级而变化。

可能的状态如下:

Sync：是所有工作备用服务器(异步服务器除外)中优先级最高的同步备用服务器的状态。

Potential：是所有正在工作的备用服务器(异步服务器除外)中优先级第二或更低的备用同步备用服务器的状态。如果同步备用程序失败，它将被替换为潜在备用程序中优先级最高的备用程序。

Async：是异步备用服务器的状态，并且该状态是固定的。

主服务器对待异步备用服务器的方式与Potential备用服务器相同，只是它们的sync_state永远不会是“sync”或“potential”。

备用服务器的优先级和状态可以通过发出以下查询来显示:​​​​​​​

postgres=# select sync_priority, sync_state from pg_stat_replication ; sync_priority | sync_state ---------------+------------             0 | async(1 row)

 

11.3.2. 主节点如何管理多个备用节点

 

主服务器只等待同步备用服务器的ACK响应。换句话说，主服务器只确认同步备用服务器写入和刷新WAL数据。因此，流复制确保只有同步备份与主备份处于一致和同步状态。

图11.3给出了Potential备服务器的ACK响应比主备机早返回的情况。在那里，主服务器没有完成当前事务的提交操作，并继续等待主服务器的ACK响应。然后，当接收到主进程的响应时，后端进程释放锁存器并完成当前事务处理。

图11.3 管理多个备用服务器

 

standby1和standby2的sync_state分别为'sync'和'potential'。尽管从潜在的备用服务器接收到ACK响应，主进程的后端进程继续等待同步备用服务器的ACK响应。(2)主进程的后端进程释放锁存器，完成当前事务处理。

在相反的情况下(即主服务器的ACK响应比潜在服务器早返回)，主服务器立即完成当前事务的提交操作，而不确保潜在备用服务器是否写和刷新WAL数据。

 

11.3.3. 故障发生时的行为

 

同样，我们来看下主服务器在备用服务器失败时的行为。

当potential或异步备用服务器发生故障时，主服务器终止连接到故障备用服务器的walsender进程，并继续所有处理。换句话说，主服务器的事务处理不会受到任何一种备用服务器故障的影响。

当同步备用服务器发生故障时，主服务器终止连接到故障备用服务器的walsender进程，并用最高优先级的潜在备用服务器替换同步备用服务器。见图11.4。与上面描述的故障相反，从故障点到替换同步备用时，主服务器上的查询处理将暂停。(因此，备用服务器的故障检测是提高复制系统可用性的一个非常重要的功能。故障检测将在下一节中描述。)

 

图11.4. 更换同步备用服务器

注：如果一个或多个备用服务器以同步模式运行，则主服务器始终只有一个同步备用服务器，同步备用服务器始终与主服务器处于一致同步状态。、

 

11.4. 检测备用服务器的故障

 

流复制使用两种常见的故障检测程序，而且不需要任何特殊的硬件。

备用服务器进程故障检测：当检测到walsender和walreceiver之间的连接断开时，主服务器立即确定备用服务器或walreceiver进程故障。当一个low level网络函数在写或读walreceiver的套接字时返回一个错误，主函数也会立即判断出备用服务器进程故障了。

 

硬件和网络的故障检测：如果walreceiver在wal_sender_timeout参数设置的时间内(默认为60秒)没有返回任何值，则主服务器判定备服务器故障。这种情况下在故障发生和检测到故障之间可能存在一段时间滞后，这种情况下，主服务器上的所有事务处理都将停止，直到检测到备用服务器的故障为止，即使多个potential的备用服务器可能正在工作。