PostgreSQL 的流复制自引入以来以稳定著称,近几年的几个大版本陆续完成了好几个大特性,例如
- 远程物理备份
- 同步流复制
- 级联流复制
- 逻辑流复制
让流复制在整个 PostgreSQL 技术方案中扮演越来越重要的角色。 本文将剖析 PostgreSQL 同步流复制的关键实现细节,希望大家喜欢。
相关概念
一.物理流复制
物理流复制是一种数据库主备同步技术,该特性同步的数据是数据库中物理页面变化数据(WAL),该模式备库的底层数据页面状态和主库完全相同,这样的实现方案让数据库主备以及同步状态都非常稳定。
二.流复制中的角色
- 主库 backend 进程,它负责执行用户的 SQL,在修改数据前会先记录 WAL(Write-Ahead Logging)日志。这些日志中事物提交日志(CommitTransaction)由 backend 进程负责写到磁盘。
- 主库 WALsender 进程,负责把 WAL 日志发送给备库的 WALreceiver 进程。
- 备库 WALreceiver 进程,负责接收 WALsender 发送的 WAL 日志,并持久化到存储。
- 备库 startup 进程,负责恢复 WALsender 写到磁盘上的 WAL 日志,把数据 apply 到数据页面上。
异步流复制和同步流复制
一.异步流复制
默认状态下的流复制是以异步方式工作的,也就是说主库写本地数据和 WAL 日志,WALsender 异步的把数据发送给备库,备库收到数据后再异步的做数据恢复。
异步模式可以做到较好的性能,它的劣势是:极端情况下,主库如果当机,被库被激活成主库,部分 WAL 没有发送到备库,可能造成数据丢失。
二.同步流复制
相对于异步模式,PostgreSQL 还支持同步模式的流复制。同模模式可以细分为三级
- REMOTE_WRITE 保证该事务的所有数据被备库收到(备库收到数据并调用 write 写磁盘,但并未持久化到磁盘)
- REMOTE_FLUSH 保证该事务的所有数据在备库持久化到磁盘(调用 flush,但只读查询看不到)
- REMOTE_APPLY 保证该事务的所有数据在备库被恢复到数据页面(恢复进程读取并解析 WAL,再 APPLY 到数据页面,在备库上执行的只读查询能看到数据的变化)
三. 同步流复制源码解析
1. MVCC 机制和数据可见性
简单的说 PostgreSQL ACID 是基于 MVCC 和 WAL 技术。数据的修改过程可以简单描述为
- 首先 backend 开启是一个事务,获得一个事务号 XID;
- 在这个事务中对数据的任意修改,都被 XID 标记。
- 其他 backend 在扫描数据时,会看到被这个 XID 修改过的数据,根据当前的隔离级别,选择对这些数据是否可见(默认的读已提交隔离级别看不到这些数据)。
- 只有当此 XID 最后被标记成 commit (写 WAL commit log 和写 clog)后,其他的 backend 才能看到这个 XID 修改的数据。
2. 同模流复制的关键点
总结一下,实现流复制的同步模式,关键点在每个事务提交或回滚时,保证它产生的所有数据变化日志,即 WAL 都“同步”到备库。最后一条 WAL commit log 尤为关键。
3. 如何实现同步流复制
铺垫完所有概念和前提技术,我们看看同步模式具体是怎么实现的。 以事务提交流程为例:
- [主库 backend 进程]调用 RecordTransactionCommit 中写 WAL commit log,获得这条日志在在 WAL 中的位置 XLogRecPtr
- [主库 backend 进程]完成写 WAL 后,进入 SyncRepWaitForLSN 等待 WAL 日志“同步”到备库。具体做法是:在共享内存中创建一个等待队列 SHMQueue 记录 XLogRecPtr,并调动 WaitLatch,让出 CPU 等待被唤醒。
- [主库 WALsender 进程]相应所有备库的 WALreceiver 拉取 WAL 的请求。把 WAL 发送给所有备库。
- [备库 WALreceiver 进程]写 WAL 的偏移(LogstreamResult.Write)和持久化 WAL 偏移(LogstreamResult.Flush)记录下来。
- [备库 startup 进程]不断的恢复数据,把当前恢复到的 WAL 位点放在共享内存 xlogctl->lastReplayedEndRecPtr 中。
- [备库 WALreceiver 进程]不断通过 r 报文和主库 WALsender 进程同步的状态,即 XLOG_WRITE_LSN XLOG_REMOTE_LSN XLOG_APPLY_LSN(XLogWalRcvSendReply)
- [主库 WALsender 进程]收到备库发送的 r 报文后,检查共享内存中的等待队列 SHMQueue, 根据备库反馈的位点结合 SHMQueue,唤醒那些等待队列中睡眠的 主库 backend 进程(WalSndWaitForWal)。
- [主库 backend 进程]被唤醒,当前事务成功提交,SQL 执行完成返回给客户端。
最后总结
本文简要分析了 PostgreSQL 同步流复制实现的关键点。整个流程比较复杂,涉及到数据库多个角色进程间的相互协作,并且使用了多种数据结构和多种进程间 IPC 通信方法。对我们了解 PostgreSQL 底层实现很有帮助。 希望能帮到想了解这部分的实现细节的朋友,谢谢。