这篇文章主要介绍了PostgreSQL 逻辑复制学习中的深入与疑问,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
首先逻辑复制早期在 PG 10 之前是通过插件的方式来实现其功能的,在PG10合并进数据库系统中。
逻辑复制主要解决的问题(是物理复制不能,或很难解决的问题)
1 表级别的复制
2 主从数据表的结构有条件的不一致
3 复制的数据进行过滤,仅仅复制 INSERT ,或者 UPATE 等操作
4 同cluster 中的不同库的的数据复制到另一个库中
如果说物理复制解决的是数据同步,数据库高可用,读写分离这方面的事情。逻辑复制应该解决的是更贴近业务,或者满足更细粒度的业务场景中的数据同步。
逻辑复制原理图
之前是有一篇逻辑复制输出其他格式的数据的文字,在下面这张图找到了他所处的层次和机理
在查看文档中,下面这张图,其中有一点不是很理解,在解码中 产生
tuplebuf * oldtuple 和 tuplebuf * newtuple 之间的意义在哪里
而图中的另一个BDR,到底是什么,这里又挖掘了一下,BDR 是2quadrant 提供的一个 异步多主逻辑复制的功能。
他定义如下四个概念
Mulit-master ,asynchronous , logical , replication
他们定义的复制是将数据从一个地方复制到另一个地方的过程。在BDR中,指的是BDR不是共享存储架构;每个节点都有自己的数据库副本,包括所有相关索引等。节点可以满足查询而不需要与其他节点通信,但是还必须有足够的存储空间来保存数据库中的所有数据
逻辑复制(基于行)是使用单个行值进行复制。它与发送数据块更改的物理(基于块的)复制形成对比。
在本地提交对一个BDR节点所做的更改之前,不会将其复制到其他节点。因此,在任何给定时间,所有节点上的数据并不完全相同;一些节点将拥有尚未到达其他节点的数据。PostgreSQL的基于块的复制解决方案也默认为异步复制。
从上面学习和了解的情况来说,从某个层面看逻辑复制有两个模块
DBR + 解码 + 解码发送 + 外部接收 几个部分组成。
其中我们已经知道 DBR 是哪里来的,而decording 是怎么回事,下面来说说
整体的decording 的过程,从上一次最后读取后的LSN号对应的事务开始,从 cache 中读取日志,如果cache 里面没有日志会在磁盘中的日志段里面读取获取日志记录,存储到结构体 xlogrecord, 然后在 logicaldecodingprocess record 模块中进行decode,然后进行循环将log 解析完毕。
在LogicalDecodingProcessRecord 是解析日志的关键,其中内存中维护一个哈希表,存放正在处理的事务信息,在处理每个日志记录是如果遇到一个begin 操作就会在哈希表中插入相应的事务,在遇到commit 会将整个事务所有的语句进行解析,每个事务都有一个快照,每次做事务都要更新快照,等到事务commit时获得最新的快照,f按岗位系统表,得到relation node id 与 relation name 之间关系信息,从而完成Decode,在完成Decode后,会调用 RecorderBuffercommit 函数,通过其中的 apply_change 函数将日志信息打印成可输出的内容,最终完成整个的Decode 过程。
感谢你能够认真阅读完这篇文章,希望小编分享的“PostgreSQL 逻辑复制学习中的深入与疑问”这篇文章对大家有帮助,同时也希望大家多多支持亿速云,关注亿速云行业资讯频道,更多相关知识等着你来学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。