来了！PostgreSQL 同步流复制原理和代码浅析，请签收

数据库 ACID 中的持久化如何实现 数据库 ACID 里面的 D，持久化。 指的是对于用户来说提交的事务，数据是可靠的，即使数据库 crash了，在硬件完好的情况下，也能恢复回来。PostgreSQL 是怎么做到的呢，看一幅图，画得比较丑，凑合看吧。假设一个事务，对数据库做了一些操作，并且产生了一些脏数据。

温馨提示：代码部分左右滑动浏览。

数据库 ACID 中的持久化如何实现

数据库 ACID 里面的 D，持久化。 指的是对于用户来说提交的事务，数据是可靠的，即使数据库 crash 了，在硬件完好的情况下，也能恢复回来。

PostgreSQL 是怎么做到的呢，看一幅图，画得比较丑，凑合看吧。

假设一个事务，对数据库做了一些操作，并且产生了一些脏数据，首先这些脏数据会在数据库的 shared buffer 中。 

同时，产生这些脏数据的同时也会产生对应的 redo 信息，产生的 REDO 会有对应的 LSN 号（你可以理解为 REDO 的虚拟地址空间的一个唯一的 OFFSET，每一笔 REDO 都有），这个 LSN 号也会记录到 shared buffer 中对应的脏页中。

walwriter 是负责将 wal buffer flush 到持久化设备的进程，同时它会更新一个全局变量，记录已经 flush 的最大的 LSN 号。

bgwriter 是负责将 shared buffer 的脏页持久化到持久化设备的进程，它在 flush 时，除了要遵循 LRU 算法之外，还要通过 LSN 全局变量的比对，来保证脏页对应的 REDO 记录已经 flush 到持久化设备了，如果发现还对应的 REDO 没有持久化，会触发 WAL writer 去 flush wal buffer。 (即确保日志比脏数据先落盘)

当用户提交事务时，也会产生一笔提交事务的 REDO，这笔 REDO 也携带了 LSN号。backend process 同样需要等待对应 LSN flush 到磁盘后才会返回给用户提交成功的信号。(保证日志先落盘，然后返回给用户) 

数据库同步复制原理浅析

同步流复制，即保证standby节点和本地节点的日志双双落盘。 

PostgreSQL 使用另一组全局变量，记录同步流复制节点已经接收到的 XLOG LSN，以及已经持久化的 XLOG LSN。

用户在发起提交请求后，backend process 除了要判断本地 wal 有没有持久化，同时还需要判断同步流复制节点的XLOG有没有接收到或持久化（通过 synchronous_commit 参数控制）。

如果同步流复制节点的 XLOG 还没有接收或持久化，backend process 会进入等待状态。

数据库同步复制代码浅析

对应的代码和解释如下：

CommitTransaction @ src/backend/access/transam/xact.c 

RecordTransactionCommit @ src/backend/access/transam/xact.c

* want these to be flushed to disk in due time.

SyncRepWaitForLSN @ src/backend/replication/syncrep.c

* * change that state to SYNC_REP_WAITING before adding ourselves * to the wait queue. During SyncRepWakeQueue() a WALSender changes * This backend then resets its state to SYNC_REP_NOT_WAITING. { * need to be connected. * set. See SyncRepUpdateSyncStandbysDefined. * * Also check that the standby hasn't already replied. Unlikely race * to be a low cost check. * * check/wait loop here. { syncRepState = MyProc->syncRepState; LWLockRelease(SyncRepLock); { { * latch, so no need for timeout.

注意用户进入等待状态后，只有主动 cancel , 或者 kill(terminate) , 或者主进程 die 才能退出无限的等待状态。后面会讲到如何将同步级别降级为异步。

前面提到了，用户端需要等待 LATCH 的释放信号。
那么谁来给它这个信号了，是 wal sender 进程，源码和解释如下 :

src/backend/replication/walsender.c

WalSndLoop ProcessStandbyMessage

SyncRepReleaseWaiters @ src/backend/replication/syncrep.c

* * perhaps also which information we store as well. { * this location. { walsndctl->lsn[SYNC_REP_WAIT_WRITE] = MyWalSnd->write; { walsndctl->lsn[SYNC_REP_WAIT_FLUSH] = MyWalSnd->flush;

SyncRepWakeQueue @ src/backend/replication/syncrep.c

* need to be woken, remove them from the queue, and then wake them. * Pass all = true to wake whole queue; otherwise, just wake up to * * Must hold SyncRepLock. { * thisproc is valid, proc may be NULL after this. &(proc->syncRepLinks), * the various states. 如何设置事务可靠性级别

PostgreSQL 支持在会话中设置事务的可靠性级别。

off 表示 commit 时不需要等待 wal 持久化。

local 表示 commit 是只需要等待本地数据库的 wal 持久化。

remote_write 表示 commit 需要等待本地数据库的 wal 持久化，同时需要等待 sync standby wal write buffer 完成(不需要持久化)。

on 表示 commit 需要等待本地数据库的 wal 持久化，同时需要等待 sync standby 节点 wal 持久化。

提醒一点， synchronous_commit 的任何一种设置，都不影响 wal 日志持久化必须先于 shared buffer 脏数据持久化。 所以不管你怎么设置，都不好影响数据的一致性。

synchronous_commit = off # synchronization level; # off, local, remote_write, or on

如何实现同步复制降级

从前面的代码解析可以得知，如果 backend process 进入了等待循环，只接受几种信号降级。 并且降级后会告警，表示本地 wal 已持久化，但是 sync standby 节点不确定 wal 有没有持久化。
如果你只配置了1个 standby，并且将它配置为同步流复制节点。一旦出现网络抖动，或者 sync standby 节点故障，将导致同步事务进入等待状态。
怎么降级呢？

方法1. 修改配置文件并重置

然后 cancel 所有 query .

postgres=# select pg_cancel_backend(pid) from pg_stat_activity where pid<>pg_backend_pid();

收到这样的信号，表示事务成功提交，同时表示 WAL 不知道有没有同步到 sync standby。

COMMIT

同时它会读到全局变量 synchronous_commit 已经是 local了。
这样就完成了降级的动作。

方法2.
方法1的降级需要对已有的正在等待 wal sync 的 pid 使用 cancel 进行处理，有点不人性化。

可以通过修改代码的方式，做到更人性化。

SyncRepWaitForLSN for 循环中，加一个判断，如果发现全局变量 sync commit 变成 local, off 了，则告警并退出。这样就不需要人为的去 cancel query 了.

原文发布时间为：2018-06-4

本文作者：德哥

本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”。