- 综合排序
- 最热优先
- 最新优先
- 来自专栏数据库干货铺
PostgreSQL主从复制--逻辑复制
1 物理复制及逻辑复制对比 前文做了PostgreSQL物理复制的部署,其有如下主要优点 物理层面完全一致，是主要的复制方式，其类似于Oracle的DG 延迟低，事务执行过程中产生REDO record 逻辑复制的复制架构图如下： ? 逻辑复制是基于逻辑解析，其核心原理是逻辑主库将Publication中表的WAL日志解析成一定格式并发送给逻辑备库，逻辑备库Subscription接收到解析后的WAL日志后进行重做，从而实现表数据同步 物理复制与逻辑复制特点和应用场景 PostgreSQL的逻辑复制与物理复制的差异比较突出，在使用中可以根据其特点选择使用哪种复制方式。 逻辑订阅，适合于发布端与订阅端都有读写的情况。 逻辑订阅，更适合于小事务，或者低密度写（轻度写）的同步。如果有大事务、高密度写，逻辑订阅的延迟相比物理复制更高。 逻辑订阅，适合于双向，多向同步。 物理复制，适合于单向同步。
5.1K31发布于 2019-10-14 - 来自专栏AustinDatabases
PostgreSQL逻辑复制槽功能
PostgreSQL 数据库的逻辑复制槽是一项非常重要的功能，通过逻辑复制槽本身，可以提供多种多样的功能。这里我们画一个思维导图进行一个全方面的分析和梳理。 PostgreSQL 逻辑复制槽 逻辑复制槽的功能可以用到多种途径，满足多种业务的需求。 4.逻辑复制槽最大的单位是针对逻辑库，而不是实例这点需要注意 psql 1 进行单逻辑库的数据库传输 在源库上创建逻辑复制槽，注意逻辑复制槽最好带有对应数据库的名字。 ALTER SUBSCRIPTION 订阅的名字 REFRESH PUBLICATION; 对于逻辑复制槽的监控需要注意 1 需要定期发现逻辑复制槽的状态 2 发现逻辑复制槽挤压WAL的文件的情况 :: 如果发现逻辑复制槽失效，或由于WAL源库的文件丢失等原因逻辑复制槽无法再消费，则必须马上删除订阅，删除逻辑复制槽。
64100编辑于 2025-03-18 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制水”好深
逻辑复制，就是那个容易出错，效率低，容易造成主从数据不一致的技术. 可能在提及逻辑复制，就会得到上面的评论，或许是MYSQL 给人的第一印象（其实我不认为逻辑复制有多不好）。 当然对比物理复制 Stream Replication 来说，逻辑的复制的效率的确是不高，并且上面被吐槽的地方都是有的。 但逻辑复制有什么好 1 我只要XX 库的数据 ，或XX表的数据，物理复制可以吗？ 2 我要做汇聚库，要 XX 库表 XX 库表 到 一个库中，进行数据分析？ 4 诶，我们要将目前的PG 10 的表复制到PG 11 那物理复制-------- NO WAY 所以一项技术的好坏先要看他是否能满足需求，所以逻辑复制好不好要看他是否能满足上面的需求。 到目前为止，逻辑复制还有一些问题需要搞清楚，在学习的过程中，发现有些怪异的问题并未有明确的文档或者解释，包含英文方面的也目前也未找到特别详细的内容。
1.5K40发布于 2019-09-18 - 来自专栏数据库相关
PG Logical Replication 逻辑复制
PG10 到 PG11 的逻辑复制 我下面演示的PG环境是单机多实例的方式部署在同一台物理机上的。部署方式可以参考 上一篇博客。 原生logical复制的限制【非常关键】: 1、只支持普通表生效，不支持序列、视图、物化视图、外部表、分区表和大对象 关于逻辑复制不支持的事项的变通方法的一些附加注释。 可以包含一张或多张表，一张表可以有一个或多个publishers 5、一个发布者可以有多个订阅者订阅，一个订阅者也可以同时订阅多个发布者，在同一个数据库下订阅者不能对同一个发布者的表重复订阅（避免数据冲突） 6、逻辑复制不同于流复制 wal_level 参数设置成 logical； 源库上逻辑复制的用户必须具有 replicatoin 或 superuser 角色； 逻辑复制目前仅支持数据库表逻辑复制，其它对象例如函数、视图不支持 ； 逻辑复制支持DML(UPDATE、INSERT、DELETE)操作，TRUNCATE 和 DDL 操作不支持； 需要发布逻辑复制的表，须配置表的 REPLICA IDENTITY 特性； 一个数据库中可以有多个
1.8K20发布于 2019-09-17 - 来自专栏移动端周边技术扩展
UITableViewCell中添加复制逻辑
_copyMenuItem) { _copyMenuItem = [[UIMenuItem alloc] initWithTitle:@"复制" action:@selector
1K40发布于 2018-06-14 - 来自专栏PostgreSQL研究与原理解析
逻辑复制的Tablesync workers
逻辑复制的Tablesync workers 富士通的OSS团队和其他OSS社区成员合作，一直在贡献代码增强PG的逻辑复制功能。 Tablesync增强 富士通 OSS 团队正在与开源社区合作，以增强 PostgreSQL 的逻辑复制。 此外，由于复制源 跟踪记录在永久槽中，这意味着可以跳过任何已经提交的数据。 杂项改进 富士通还在 PostgreSQL 逻辑复制领域贡献了许多其他错误修复和小改进，我们定期参与对其他贡献补丁的审查。 以下是我们在其他人的帮助下编写的更多 PostgreSQL 14 更改： 1）重命名逻辑复制全局“wrconn” 2）改进一些与复制相关的错误消息的样式 3）修复stream_cleanup_files 中的悬空指针引用 4）澄清tablesync.c中的注释 5）修复同一个表的多个复制截断的死锁 6）在更多地方使用Enums进行逻辑复制消息类型 好处 对 Tablesync Worker 所做的改进有助于进行逻辑复制
86620编辑于 2022-06-21 - 来自专栏开源部署
PostgreSQL逻辑复制之slony篇
Slony是PostgreSQL领域中最广泛的复制解决方案之一。它不仅是最古老的复制实现之一，它也是一个拥有最广泛的外部工具支持的工具，比如pgAdmin3。 多年来，Slony是在PostgreSQL中复制数据的惟一可行的解决方案。 Slony使用逻辑复制；Slony-I一般要求表有主键,或者唯一键；Slony的工作不是基于PostgreSQL事务日志的；而是基于触发器的；基于逻辑复制高可用性；PostgreSQL除了slony；还有 复制表 现有实验环境： 主机名 IP 角色 PostgreSQL201 192.168.1.201 master PostgreSQL202 192.168.1.202 slave 3.1 在两台数据库中都创建一个 superuser password 'li0924'; 3.2 本实验两台主机都有lottu数据库；以lottu数据库中的表作为实验对象；在两个数据库中以相同的方式创建该表synctab，因为表结构不会自动复制
72120编辑于 2022-08-16 - 来自专栏云云众生s
解决PostgreSQL逻辑复制的挑战
分布式 Postgres 供应商 pgEdge 继续通过其最新版本（称为“星座版”）来解决 逻辑复制 的复杂性，该版本提供了增强的并行处理、大对象支持和错误处理。 尽管 Postgres 中的逻辑复制 是一项强大的功能，但它也存在一些挑战，包括一致性、同步、冲突解决和开销，这些都会影响性能。 星座版的功能包括： 大型对象逻辑复制 (LOLOR): 此 PostgreSQL 插件替换使现有应用程序的媒体资产（例如二进制文件、图像和其他非关系数据类型）与逻辑复制兼容。 尽管 Postgres 支持将大型对象作为目录表中的块进行存储，但复制这些表需要特殊处理，根据其 大型对象逻辑复制 (LOLOR) GitHub 页面 所述。 它根据逻辑更改（例如插入、更新和删除操作）而不是存储级别的物理更改来复制数据，并使用 更改数据捕获 来确保与其他数据库实例的近乎实时的同步。
40710编辑于 2024-08-12 - 来自专栏AustinDatabases
PostgreSQL 通过python 监控逻辑复制
本期是通过PYTHON 来对逻辑复制中的配置参数，publication 定义， 打印不适合进行逻辑复制的表，打印没有在使用的复制槽，另外包含当前发布端和接收端两边的LSN对比。 以下是代码，对于逻辑复制中主要的监控点有 1 是不是存在复制槽不使用的情况 2 是不是存在主库和从库之间的复制延迟（异步） 3 当前库是不是存在不适合进行逻辑复制的表 4 当前库是不是有设置发布 /usr/bin/python3 import os import sys import psycopg2 import re import subprocess #检测当前PG是否具备进行逻辑复制的参数配置 ("""show max_wal_senders;""") rows = cur.fetchall() for row in rows: print("启用逻辑复制,请注意最大 另逻辑复制中最怕的是接收端数据出现问题，导致复制停止，目前需要通过日志来查询出现的问题。程序里面并未有及时分析日志的部分。
1K30发布于 2021-11-17 - 来自专栏开源部署
PostgreSQL逻辑复制之pglogical篇
一、pglogical介绍 pglogical 是 PostgreSQL 的拓展模块, 为 PostgreSQL 数据库提供了逻辑流复制发布和订阅的功能。 pglogical 是一个完全作为PostgreSQL 扩展实现的逻辑复制系统。完全集成，它不需要触发器或外部程序。这种物理复制的替代方法是使用发布/订阅模型复制数据以进行选择性复制的一种高效方法。 扩展模块复制的基本用法。 pg_config USE_PGXS=1 make clean USE_PGXS=1 make USE_PGXS=1 make install 首先 PostgreSQL服务器必须正确配置才能够支持逻辑解码 table tbl_lottu05(id int primary key,name text); CREATE TABLE 5.1.2、搭建模拟场景 更多介绍查看第三节；或者查考《PostgreSQL 逻辑复制文档
3K10编辑于 2022-08-18 - 来自专栏AustinDatabases
PostgreSQL 的逻辑复制 与 部分疑问
PostgreSQL 本身是支持流式复制的，而大部分数据库都支持逻辑复制的方式，流式复制稳定高效，但缺点是不灵活，而逻辑复制的优点就在于此。 逻辑的复制的优点 1 可以进行数据的过滤 2 可以进行数据的融合 3 部分数据的复制 逻辑复制使用发布/订阅模型，因此我们在上游(或发布者)创建发布，在下游(或订阅者)创建订阅。 通过一个例子我们来进行实际的逻辑复制的理解 1 先在原库上创建一张表 ? 此时复制已经中断 总结：数据复制中，如果选择复制所有表，在添加新表后，需要在从库也建立相关的表结构。如果不做则表复制就直接错误并不在进行工作。 如何恢复，直接在从库上建立表的结构后，数据就开始复制 ，并且复制自动开始，复制恢复。
1.7K30发布于 2019-07-08 - 来自专栏cwl_Java
数据库PostrageSQL-逻辑复制
逻辑复制 逻辑复制是一种基于数据对象的复制标识（通常是主键）复制数据对象及其更改的方法。我们使用术语“逻辑”来与物理复制加以区分，后者使用准确的块地址以及逐字节的复制方式。 逻辑复制允许在数据复制和安全性上更细粒度的控制。 逻辑复制使用一种发布和订阅模型，其中有一个或者更多订阅者订阅一个发布者节点上的一个或者更多publication 。 订阅者从它们所订阅的publication拉取数据并且可能后续重新发布这些数据以允许级联复制或者更复杂的配置。 一个表的逻辑复制通常开始于对发布者服务器上的数据取得一个快照并且将快照拷贝给订阅者。 这种数据复制的方法有时候也被称为事务性复制。逻辑复制的典型用法是： 在一个数据库或者一个数据库的子集中发生更改时，把增量的改变发送给订阅者。 在更改到达订阅者时引发触发器。 在PostgreSQL的不同主版本之间进行复制。 在不同平台上（例如Linux到Windows）的PostgreSQL实例之间进行复制。 将复制数据的访问给予不同的用户组。
1.2K10发布于 2021-01-13 - 来自专栏运维小路
PostgreSQL-逻辑复制（Logic）部署方案
MySQL PostgreSQL（本章节） MongoDB Redis Etcd 上个小节我们完成PGSQL基于WAL的流复制的主从集群搭建，这个虽然底层的复制逻辑不一样，但是他和MySQL主从一样都可以作为集群的高可用来使用的 但是我们今天讲的逻辑复制，考虑的就只是复制自己想要的数据，其他不相关的数据都是不复制，这个小节就来介绍如何配置逻辑复制。 #修改postgresql.conf wal_level = logical # 开启逻辑复制模式 max_replication_slots = 5 # 预留足够的复制槽 max_wal_senders CREATE ROLE repl_user WITH REPLICATION -- 授予复制权限（逻辑复制必需） LOGIN -- 允许该角色登录数据库 0/30290A8 | 2025-11-06 23:28:43.307229+08 (1 row) 8.插入数据验证 这个时候我们向源库表插入数据，只有配置了订阅的表才会同步过来，因为他的逻辑是表对表进行复制
16310编辑于 2026-01-26 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制的“水”还是深
接上期的问题，在删除postgresql的 逻辑复制时遇到了一些麻烦，删除subscription时遇到了 ? 3 我们查看日志，以及监控，查看复制是否建立 复制建立 ? 复制槽工作中 ? 从库订阅已经建立 ? 模拟情况 1 删除subscription 失败 ? 所以在复制订阅中的订阅停止后，如果确认订阅无法再次恢复，或者不确认多长时间恢复，则需要删除复制槽 select * from pg_replication_slots； select pg_drop_replication_slot 以上就是在学习和处理逻辑复制中遇到的问题。当然如果你认为目前的问题就到此为止了，那就错了，其实复制订阅的水，还有很多没有踩。 到此复制订阅，告一段落，其实里面还有很多的东西没有说，通过学习复制订阅，发现学习一件事情，更多的是需要发散性的需求，如果仅仅是 单向思维，基本上没有什么事情是不好做的，用发散性思维去考虑问题，则需要解决的问题会很多
1.5K20发布于 2019-09-19 - 来自专栏bisal的个人杂货铺
PG逻辑复制的REPLICA IDENTITY设置
首先了解下，逻辑复制的概念。逻辑复制是PostgreSQL V10重量级新特性，支持内置的逻辑复制。 从9.4版本开始，PostgreSQL就支持逻辑复制了，只是一直没有将其引入内核。可以针对同一个数据库实例，同时使用逻辑复制和物理复制，因为他们都是基于REDO的。 逻辑复制原理，使用发布者/订阅者模型，使用订阅复制槽技术，可并行的传输WAL日志，通过在订阅端回放WAL日志中的逻辑条目，保持复制表的数据同步，注意这里不是“SQL”复制，而是复制SQL操作的结果。 关于发布端和订阅端， (1) 发布端 逻辑复制的前提是将数据库wal_level参数设置成logical。 源库上逻辑复制的用户必须具有replicatoin或superuser角色。 逻辑复制目前仅支持数据库表逻辑复制，其它对象例如函数、视图不支持。 逻辑复制支持DML(UPDATE、INSERT、DELETE)操作，TRUNCATE 和 DDL 操作不支持。
3.2K31发布于 2021-09-06 - 来自专栏PostgreSQL研究与原理解析
PostgreSQL 13、14中逻辑复制解码改进
/ 事实上，没有什么比这个问题更能伤害逻辑复制了。 随着最大的缺陷消失，我们预计会有越来越多的用户开始研究或重新考虑逻辑复制，尤其是那些由于实际困难而放弃它的用户。我想让他们知道PG13和14等版本中，还有更多与逻辑复制/解码相关的令人兴奋的新功能。 系统正忙于检查溢出文件并准备提交顺序，需要将其发送到逻辑副本。 同样，我们见证了一些用户选择逻辑复制以减少主节点负载的案例。但是WAL sender在逻辑解码期间的复杂性抹杀了所有潜在的收益。 逻辑复制的整体逻辑和特性必须经历巨大变化。但是PG14引入了将reorderbuffer流式传输到订阅者而不是先溢出到磁盘的选项。显然，流式传输正在运行的事务这个新功能需要复制协议的改进。 当有人设置逻辑复制时，这是一个很大的增值。
99920编辑于 2022-03-29 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制学习中的深入与疑问
首先逻辑复制早期在 PG 10 之前是通过插件的方式来实现其功能的，在PG10合并进数据库系统中。 逻辑复制主要解决的问题（是物理复制不能，或很难解决的问题） 1 表级别的复制 2 主从数据表的结构有条件的不一致 3 复制的数据进行过滤，仅仅复制 INSERT ，或者 UPATE 等操作 逻辑复制应该解决的是更贴近业务，或者满足更细粒度的业务场景中的数据同步。 逻辑复制原理图 ? 之前是有一篇逻辑复制输出其他格式的数据的文字，在下面这张图找到了他所处的层次和机理 ? 而图中的另一个BDR,到底是什么，这里又挖掘了一下，BDR 是2quadrant 提供的一个 异步多主逻辑复制的功能。 节点可以满足查询而不需要与其他节点通信，但是还必须有足够的存储空间来保存数据库中的所有数据 逻辑复制(基于行)是使用单个行值进行复制。它与发送数据块更改的物理(基于块的)复制形成对比。
1.4K20发布于 2019-11-24 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制一网打尽
在提到POSTGRESQL的逻辑复制之前，还是的先说说逻辑复制的应用场景，以及与物理复制的不同和操作中的注意事项。 1 场景： 逻辑复制的场景主要包含 1 数据的跟踪与捕捉，如数据抽取与数据的汇聚 2 数据大表的迁移，通过逻辑复制可以量数据表从一个PG的服务器迁移到另一个物理的服务器 3 PG 物理服务器升级中大表的数据转移 ，实际上逻辑复制中有很多的搭配和选择，同时逻辑复制也会有诸多的问题，下面通过事例来进行解释 例 1 对一张表中的DML 操作有挑选的进行工作，如在操作中只进行insert 和 update 的操作的提取 如下面的一些错误 例 2 在逻辑复制中添加表或者删除表 逻辑复制中最灵活的方案就是对于需要复制的表进行添加和删除，通过alter publication 的方式来添加表 1 我们在publication 另外逻辑复制中也有一些问题是需要注意和知晓的 1 在高可用的环境下，如果主机切换，逻辑复制是无法进行切换的 2 如果在设置复制为同步模式，则可能在部分情况下引起主库commit的性能问题
1.1K20发布于 2021-11-17 - 来自专栏PostgreSQL 记录
PostgreSQL 逻辑复制大事务处理的演进
1前言接上篇《进击的逻辑复制》未完话题——大事务。众所周知，逻辑复制处理大事务一直比较头疼，不仅会导致性能下降，还会导致延迟。从 13 版本以来，每个大版本在对大事务的处理方面都有显著的提升。 不过这块我倒是没有看到类似的等待事件，要是有类似的等待事件的话，也可以作为分析逻辑复制的一个手段。 这限制了逻辑流复制连接使用的内存量。默认为 64 MB。 3小结可以看到，社区一直在不断优化着逻辑复制的功能，相信在今年发布的 16 中，逻辑复制的能力会有一个质的飞跃。 另外分享一个逻辑复制演进合订本 请叫我雷锋4参考编号说明1PostgreSQL 逻辑复制2CREATE PUBLICATION — 定义一个新的发布3CREATE SUBSCRIPTION — 定义一个新的订阅
79130编辑于 2023-07-31 - 来自专栏数据和云
24日直播预告丨PostgreSQL逻辑复制案例分享
PostgreSQL逻辑复制案例分享——2月24日20:00 在PostgreSQL和基于PostgreSQL的国产数据库的使用中，逻辑复制作为一种区别于流复制的数据同步功能，常用于主业务库向分析库的数据同步 、归并与汇总，逻辑复制具有更灵活的使用场景。 但使用逻辑复制的同时，也有一些需要注意的坑。本次分享邀请到云和恩墨PG技术顾问阎书利老师，通过以往项目经验以及一起生产案例来讲述逻辑复制需要注意的点，尽可能避免后期生产故障的发生。 演讲提纲：1.逻辑复制介绍及原理2.一起逻辑复制槽引发wal异常的生产案例3.解析PG清除wal原理4.关于逻辑复制的细节及建议 适合人群： PostgreSQL数据库工程师，基于PostgreSQL
37030编辑于 2022-03-04
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号