PgSQL · 内核解析 · 同步流复制实现分析-阿里云开发者社区

开发者社区> 数据库> 正文

PgSQL · 内核解析 · 同步流复制实现分析

简介:

PostgreSQL 的流复制自引入以来以稳定著称,近几年的几个大版本陆续完成了好几个大特性,例如

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

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

相关概念

一.物理流复制

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

二.流复制中的角色

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

异步流复制和同步流复制

一.异步流复制

默认状态下的流复制是以异步方式工作的,也就是说主库写本地数据和 WAL 日志,WALsender 异步的把数据发送给备库,备库收到数据后再异步的做数据恢复。

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

二.同步流复制

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

    1. REMOTE_WRITE 保证该事务的所有数据被备库收到(备库收到数据并调用 write 写磁盘,但并未持久化到磁盘)
    1. REMOTE_FLUSH 保证该事务的所有数据在备库持久化到磁盘(调用 flush,但只读查询看不到)
    1. REMOTE_APPLY 保证该事务的所有数据在备库被恢复到数据页面(恢复进程读取并解析 WAL,再 APPLY 到数据页面,在备库上执行的只读查询能看到数据的变化)

三. 同步流复制源码解析

1. MVCC 机制和数据可见性

简单的说 PostgreSQL ACID 是基于 MVCC 和 WAL 技术。数据的修改过程可以简单描述为

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

2. 同模流复制的关键点

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

3. 如何实现同步流复制

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

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

最后总结

本文简要分析了 PostgreSQL 同步流复制实现的关键点。整个流程比较复杂,涉及到数据库多个角色进程间的相互协作,并且使用了多种数据结构和多种进程间 IPC 通信方法。对我们了解 PostgreSQL 底层实现很有帮助。 希望能帮到想了解这部分的实现细节的朋友,谢谢。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章