• 1.远程物理备份
  • 2.同步流复制
  • 3.级联流复制
  • 4.逻辑流复制

让流复制在整个 PostgreSQL 技术方案中扮演越来越重要的角色。 本文将剖析 PostgreSQL 同步流复制的关键实现细节，希望大家喜欢。

物理流复制是一种数据库主备同步技术，该特性同步的数据是数据库中物理页面变化数据（WAL），该模式备库的底层数据页面状态和主库完全相同，这样的实现方案让数据库主备以及同步状态都非常稳定。

  • 1. 主库 backend 进程，它负责执行用户的 SQL，在修改数据前会先记录 WAL（Write-Ahead Logging）日志。这些日志中事物提交日志（CommitTransaction）由 backend 进程负责写到磁盘。
  • 2. 主库 WALsender 进程，负责把 WAL 日志发送给备库的 WALreceiver 进程。
  • 3. 备库 WALreceiver 进程，负责接收 WALsender 发送的 WAL 日志，并持久化到存储。
  • 4. 备库 startup 进程，负责恢复 WALsender 写到磁盘上的 WAL 日志，把数据 apply 到数据页面上。

异步模式可以做到较好的性能，它的劣势是：极端情况下，主库如果当机，被库被激活成主库，部分 WAL 没有发送到备库，可能造成数据丢失。

相对于异步模式，PostgreSQL 还支持同步模式的流复制。同模模式可以细分为三级

  • 1. REMOTE_WRITE 保证该事务的所有数据被备库收到（备库收到数据并调用 write 写磁盘，但并未持久化到磁盘）
  • 2. REMOTE_FLUSH 保证该事务的所有数据在备库持久化到磁盘（调用 flush，但只读查询看不到）

1. MVCC 机制和数据可见性

  • 1. 首先 backend 开启是一个事务,获得一个事务号 XID;
  • 2. 在这个事务中对数据的任意修改，都被 XID 标记。
  • 3. 其他 backend 在扫描数据时，会看到被这个 XID 修改过的数据，根据当前的隔离级别，选择对这些数据是否可见（默认的读已提交隔离级别看不到这些数据）。
  • 4. 只有当此 XID 最后被标记成 commit （写 WAL commit log 和写 clog）后，其他的 backend 才能看到这个 XID 修改的数据。

2. 同模流复制的关键点

总结一下，实现流复制的同步模式，关键点在每个事务提交或回滚时，保证它产生的所有数据变化日志，即 WAL 都“同步”到备库。最后一条 WAL commit log 尤为关键。

3. 如何实现同步流复制

铺垫完所有概念和前提技术，我们看看同步模式具体是怎么实现的。 以事务提交流程为例：

  • 1. [主库 backend 进程]调用 RecordTransactionCommit 中写 WAL commit log，获得这条日志在在 WAL 中的位置 XLogRecPtr
  • 2. [主库 backend 进程]完成写 WAL 后，进入 SyncRepWaitForLSN 等待 WAL 日志“同步”到备库。具体做法是:在共享内存中创建一个等待队列 SHMQueue 记录 XLogRecPtr，并调动 WaitLatch，让出 CPU 等待被唤醒。
  • 3. [主库 WALsender 进程]相应所有备库的 WALreceiver 拉取 WAL 的请求。把 WAL 发送给所有备库。
  • 4. [备库 WALreceiver 进程]写 WAL 的偏移（LogstreamResult.Write）和持久化 WAL 偏移（LogstreamResult.Flush）记录下来。
  • 5. [备库 startup 进程]不断的恢复数据，把当前恢复到的 WAL 位点放在共享内存 xlogctl->lastReplayedEndRecPtr 中。
  • 6. [备库 WALreceiver 进程]不断通过 r 报文和主库 WALsender 进程同步的状态，即 XLOG_WRITE_LSN XLOG_REMOTE_LSN XLOG_APPLY_LSN（XLogWalRcvSendReply）
  • 8. [主库 backend 进程]被唤醒，当前事务成功提交，SQL 执行完成返回给客户端。