PostgreSQL 同步复制原理解析

背景

Postgresql 在主备架构的场景下，支持同步流复制功能。本文将以一主一备架构为例，介绍同步流复制（同步备机）的工作方式以及内核代码的相关原理。

配置同步备机

工欲善其事，必先利其器。我们现简单的配置一个同步备机，方便后续调试研究代码。
首先配置主库，并使用 pg_basebackup 拉起一个备库

-- 主库添加流复制用户
create role repl login replication;

-- 主库 pg_hba.conf 加一行
host    replication     repl        127.0.0.1/32                 trust

-- 拉起备库
./pg_basebackup -h localhost -U repl -p 5432  -P -v  -R -X stream -D ../data_b -l backup_label
echo "port = 5433" >> ../data_b/postgresql.conf
echo "hot_standby = on" >> ../data_b/postgresql.conf
./pg_ctl start -D ../data_b -l logfile_b
1
2
3
4
5
6
7
8
9
10
11

这时候，主备之间还属于异步复制状态，需要主库设置以下两个参数配置同步复制。

alter system set synchronous_commit = on;
alter system set synchronous_standby_names='walreceiver';
select pg_reload_conf();
1
2
3

现在备机已属于同步状态

为了方便后续调试，设置下面两个参数

client_min_messages=LOG
wal_debug=on
1
2

场景分析

首先使用 gdb 卡住备库的 walreceiver 进程，这时候主库执行一条 insert 语句，其结果如下

主库写了两条 XLOG，然后卡住不动：

1. insert 记录；
2. commit 记录。

此时使用 gdb 去看主库，发现其卡在 SyncRepWaitForLSN 函数中等待 latch。当我们释放卡住备库 walreceiver 进程的 gdb 后，latch 被唤醒，该事物最终被标记为提交。

原理分析

其大致原理如下图所示，主库刷完 XLOG 后，在 SyncRepWaitForLSN 函数中等待 latch。

接下来详细介绍下主库等待、唤醒这一套的实现机制，首先需要熟悉以下变量和函数：

• SyncRepQueue：维护在共享内存中的队列。位于 WalSndCtlData 结构体中，可用于处理同步复制中的同步关系（备库 XLOG 落盘停止阻塞）。用于维护需要等待同步提交的进程队列；
• SyncRepQueueInsert：主库 SyncRepWaitForLSN 函数调用，作用是把该进程插入 SyncRepQueue 队列中，然后开始等待；
• SyncRepCancelWait：停止等待，并将该进程从队列中移除；
• SyncRepWakeQueue：唤醒队列中所有等待的进程，并将所有进程移除队列；

具体流程如下：

1. 主库插入数据，刷 XLOG；
2. 调用 SyncRepWaitForLSN 等待，并将本进程插入 SyncRepQueue 队列中；
3. 备库 walreceiver 进程将 XLOG 刷入磁盘，并且通知主库的 walsender 进程；
4. 主库 walsender 进程收到备库的消息，使用 SyncRepWakeQueue 唤醒所有等待队列中的进程，并将其移出队列；
5. 主库执行 SQL 的进程继续执行，通知其他进程本事物已提交。
   

数据一致性讨论

这里由于主库先写了 XLOG 并且已落盘，如果此时：

1. 主库 crash ；
2. 备库尚未收到这条 xlog，但是 promote；
3. 主库启动，走 recovery 流程。

那么就会出现一个场景：第 3 步主库会把这条数据恢复出来，而备库 promote 后就不会有这条数据了。由于 promote 的存在，这里我们仍然认为数据是一致的（如果不 promote，该条事物终究会在备库提交）。