- 综合排序
- 最热优先
- 最新优先
- 来自专栏数据库干货铺
PostgreSQL主从复制--逻辑复制
1 物理复制及逻辑复制对比 前文做了PostgreSQL物理复制的部署,其有如下主要优点 物理层面完全一致，是主要的复制方式，其类似于Oracle的DG 延迟低，事务执行过程中产生REDO record 逻辑复制的复制架构图如下： ? ：设置逻辑复制进程数，应大于订阅节点的数量，并且给表同步预留一些进程数量，此参数默认值为4 2.3 创建逻辑复制账号 postgres=# CREATE USER logical_repl REPLICATION 物理复制与逻辑复制特点和应用场景 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 - 来自专栏数据库相关
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 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制水”好深
逻辑复制，就是那个容易出错，效率低，容易造成主从数据不一致的技术. 可能在提及逻辑复制，就会得到上面的评论，或许是MYSQL 给人的第一印象（其实我不认为逻辑复制有多不好）。 当然对比物理复制 Stream Replication 来说，逻辑的复制的效率的确是不高，并且上面被吐槽的地方都是有的。 但逻辑复制有什么好 1 我只要XX 库的数据 ，或XX表的数据，物理复制可以吗？ 2 我要做汇聚库，要 XX 库表 XX 库表 到 一个库中，进行数据分析？ 4 诶，我们要将目前的PG 10 的表复制到PG 11 那物理复制-------- NO WAY 所以一项技术的好坏先要看他是否能满足需求，所以逻辑复制好不好要看他是否能满足上面的需求。 带着这个问题我们做下一个实验 1 我建立一个publication 2 我备份数据库 3 期间我添加数据在publication端 4 我恢复数据库 5 建立subscription查看 在3
1.5K40发布于 2019-09-18 - 来自专栏移动端周边技术扩展
UITableViewCell中添加复制逻辑
_copyMenuItem) { _copyMenuItem = [[UIMenuItem alloc] initWithTitle:@"复制" action:@selector
1K40发布于 2018-06-14 - 来自专栏PostgreSQL研究与原理解析
逻辑复制的Tablesync workers
逻辑复制的Tablesync workers 富士通的OSS团队和其他OSS社区成员合作，一直在贡献代码增强PG的逻辑复制功能。 Tablesync增强 富士通 OSS 团队正在与开源社区合作，以增强 PostgreSQL 的逻辑复制。 此外，由于复制源 跟踪记录在永久槽中，这意味着可以跳过任何已经提交的数据。 杂项改进 富士通还在 PostgreSQL 逻辑复制领域贡献了许多其他错误修复和小改进，我们定期参与对其他贡献补丁的审查。 中的悬空指针引用 4）澄清tablesync.c中的注释 5）修复同一个表的多个复制截断的死锁 6）在更多地方使用Enums进行逻辑复制消息类型 好处 对 Tablesync Worker 所做的改进有助于进行逻辑复制 ： 1) 在失败的情况下更强大 2) 更高效（对于能够避免昂贵的表重新COPY（如果已经提交）的场景） 3) 更一致（多事务逻辑与 Apply Worker 相同） 4) 更稳定（通过错误修复） 原文
86620编辑于 2022-06-21 - 来自专栏技术杂记
Redis 复制4
redis-3.0.0.tar.gz redis-new.conf tmp[root@m1 ~]# redis-cli 127.0.0.1:6379> keys * 1) "b"2) "a"3) "c"4)
27710编辑于 2022-07-09 - 来自专栏云云众生s
解决PostgreSQL逻辑复制的挑战
尽管 Postgres 中的逻辑复制 是一项强大的功能，但它也存在一些挑战，包括一致性、同步、冲突解决和开销，这些都会影响性能。 星座版的功能包括： 大型对象逻辑复制 (LOLOR): 此 PostgreSQL 插件替换使现有应用程序的媒体资产（例如二进制文件、图像和其他非关系数据类型）与逻辑复制兼容。 尽管 Postgres 支持将大型对象作为目录表中的块进行存储，但复制这些表需要特殊处理，根据其 大型对象逻辑复制 (LOLOR) GitHub 页面 所述。 它根据逻辑更改（例如插入、更新和删除操作）而不是存储级别的物理更改来复制数据，并使用 更改数据捕获 来确保与其他数据库实例的近乎实时的同步。 虽然将这些功能列为本次发布的一部分，但该公司在 4 月宣布了自动数据定义语言 (DDL) 复制和 Snowflake 序列。
40710编辑于 2024-08-12 - 来自专栏开源部署
PostgreSQL逻辑复制之slony篇
Slony是PostgreSQL领域中最广泛的复制解决方案之一。它不仅是最古老的复制实现之一，它也是一个拥有最广泛的外部工具支持的工具，比如pgAdmin3。 多年来，Slony是在PostgreSQL中复制数据的惟一可行的解决方案。 Slony使用逻辑复制；Slony-I一般要求表有主键,或者唯一键；Slony的工作不是基于PostgreSQL事务日志的；而是基于触发器的；基于逻辑复制高可用性；PostgreSQL除了slony；还有 as user "lottu". lottu=> select * from synctab ; id | name ------+------- 1001 | lottu (1 row) 4. /slony_drop_node.sh <stdin>:4: NOTICE: Slony-I: Please drop schema "_first_cluster" <stdin>:4: NOTICE
72120编辑于 2022-08-16 - 来自专栏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服务器必须正确配置才能够支持逻辑解码 | lottu4 | pg 5 | lottu5 | pg 6 | lottu6 | pg 7 | lottu7 | pg 8 | lottu8 | pg 9 | lottu9 | 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 先在原库上创建一张表 ? 4 直接在从库的错误日志中可以看到明显的错误提示 ? 此时复制已经中断 总结：数据复制中，如果选择复制所有表，在添加新表后，需要在从库也建立相关的表结构。 4 在从库进行数据的修改 这里就不在截图，直接将结果展现 如果你对从库的表的数据进行UPDATE 非主键的情况下，其实对于复制的影响并不是很大，但不建议这样做。
1.7K30发布于 2019-07-08 - 来自专栏运维小路
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 -- 允许该角色登录数据库 simple_table ( id SERIAL PRIMARY KEY, name VARCHAR(100), created_at TIMESTAMP DEFAULT NOW() ); 4.
16310编辑于 2026-01-26 - 来自专栏mysql-dba
mysql复制系列4-半同步复制
mysql复制包括异步复制和半同步复制： 异步复制：主库将事件写入二进制日志，但不知道从库是否接收成功，也不知道从库什么时候重放二进制日志，如果主库崩溃，则在主库提交的事务可能还没有传输到从库，这种情况下如果主从故障切换 mysql对复制进行了改进，引入了半同步复制，半同步复制是以插件的形式进行安装。 relay log中，这样就避免了异步复制主库宕机可能存在的日志丢失问题了。 mysql5.7增强半同步复制： rpl_semi_sync_master_wait_point的配置（控制半同步复制中在主库返回事务提交状态信息给客户端之前，等待从库ack消息的位点） after_sync :控制主库在超时切换到异步复制之前，等待从库返回ack消息的时间 状态变量： rpl_semi_sync_master_clients:显示半同步复制从库的数量 rpl_semi_sync_master_status
97241发布于 2021-05-13 - 来自专栏cwl_Java
数据库PostrageSQL-逻辑复制
逻辑复制 逻辑复制是一种基于数据对象的复制标识（通常是主键）复制数据对象及其更改的方法。我们使用术语“逻辑”来与物理复制加以区分，后者使用准确的块地址以及逐字节的复制方式。 逻辑复制允许在数据复制和安全性上更细粒度的控制。 逻辑复制使用一种发布和订阅模型，其中有一个或者更多订阅者订阅一个发布者节点上的一个或者更多publication 。 订阅者从它们所订阅的publication拉取数据并且可能后续重新发布这些数据以允许级联复制或者更复杂的配置。 一个表的逻辑复制通常开始于对发布者服务器上的数据取得一个快照并且将快照拷贝给订阅者。 这种数据复制的方法有时候也被称为事务性复制。逻辑复制的典型用法是： 在一个数据库或者一个数据库的子集中发生更改时，把增量的改变发送给订阅者。 在更改到达订阅者时引发触发器。 在PostgreSQL的不同主版本之间进行复制。 在不同平台上（例如Linux到Windows）的PostgreSQL实例之间进行复制。 将复制数据的访问给予不同的用户组。
1.2K10发布于 2021-01-13 - 来自专栏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操作的结果。 逻辑复制目前仅支持数据库表逻辑复制，其它对象例如函数、视图不支持。 逻辑复制支持DML(UPDATE、INSERT、DELETE)操作，TRUNCATE 和 DDL 操作不支持。 (4) 无身份模式(nothing)：不记录任何复制标识，这意味着UPDATE|DELETE操作无法复制到订阅者上。 表改复制标识可以通过ALTER TABLE进行修改。
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 等操作 4 同cluster 中的不同库的的数据复制到另一个库中 如果说物理复制解决的是数据同步，数据库高可用，读写分离这方面的事情。 逻辑复制应该解决的是更贴近业务，或者满足更细粒度的业务场景中的数据同步。 逻辑复制原理图 ? 之前是有一篇逻辑复制输出其他格式的数据的文字，在下面这张图找到了他所处的层次和机理 ? 节点可以满足查询而不需要与其他节点通信，但是还必须有足够的存储空间来保存数据库中的所有数据 逻辑复制(基于行)是使用单个行值进行复制。它与发送数据块更改的物理(基于块的)复制形成对比。
1.4K20发布于 2019-11-24 - 来自专栏AustinDatabases
PostgreSQL 逻辑复制一网打尽
在提到POSTGRESQL的逻辑复制之前，还是的先说说逻辑复制的应用场景，以及与物理复制的不同和操作中的注意事项。 4 数据的拆分和特定场景的数据处理，如复制仅仅进行insert操作，记录一个表中数据的原始记录等等 5 对原表的数据进行更多函数计算并直接落入复制表中 2 与物理复制的不同 1 仅仅提取数据库中指定数据表的 DML数据输出 2 可以进行CDC的操作，获取数据进行异构数据库表的数据同步 3 数据复制中性能相对物理复制会比较差 4 对于复制的表时有要求的，（对比物理复制） 5 需要逻辑复制槽的支持 如下面的一些错误 例 2 在逻辑复制中添加表或者删除表 逻辑复制中最灵活的方案就是对于需要复制的表进行添加和删除，通过alter publication 的方式来添加表 1 我们在publication 另外逻辑复制中也有一些问题是需要注意和知晓的 1 在高可用的环境下，如果主机切换，逻辑复制是无法进行切换的 2 如果在设置复制为同步模式，则可能在部分情况下引起主库commit的性能问题
1.1K20发布于 2021-11-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号