PostgreSQL的逻辑复制对比物理复制的好处总结有如下几点
微信
1 灵活: 逻辑复制对比物理复制来讲,能够单表进行数据的复制,物理复制则是不能够的,而且大部分时间对于ETL的功能需求来讲,物理复制过重了,须要的磁盘,网络,等资源都相对于逻辑复制消耗的要大的多. 网络
2 方便:逻辑复制相对于物理复制,设置会更简单,能够随时终止或者建立,数据进行同步等等.架构
3 定制化:逻辑复制能够设置复制的操做,例如只须要进行insert 的复制,或者 update, delete 等操做的复制,能够作到, 数据不和primary端一致,而达到某些目的..net
4 数据迁移,PG若是版本不一样进行升级的状况下,PG的logical replication 是能够做为一种数据迁移的方案,在不一样的版本中进行数据的同步使用的.3d
逻辑复制仍是使用物理复制架构实现,从上图可见, 在复制槽的基础上添加了pgoutput plugin 将原有的wal 日志转换后发送, subscription 在接受这些信息,将信息填充到目的地. 为了不数据被重复的在subscription 上重复操做,经过客户端记录接受的LSN号码,避免重复接受一样的数据,并操做.
日志
另外须要提示的是,不少不能进行vacuum的案例中,部分都有复制槽的出现,可能这个复制槽一主多用,同时有数据接收端,其中若是有数据接收端没法接受数据,则与相关的须要保留的tuples 就不会被清理,形成 vacuum 没法回收.
blog
下面咱们有一个复制槽
ip
而后咱们人为的制造一个冲突. 在数据复制的从库,将数据表的人为添加了一条数据.
资源
在subscription 端查看subscription 的信息
get
而后咱们在publication 端也插入数据
直接进入到subscription 中查看错误日志
系统一直在报错的状态中, 因为主库和从库之间的数据操做冲突,致使从主库到从库的数据没法被操做. 那究竟是怎么影响了WAL log
咱们继续往下看
在主库咱们将2000条数据删除1900条
在subscription 中咱们查看当前的数据,结果必定是和主库已经脱离,不会在继续进行任何操做,主要的缘由也是 逻辑复制是有顺序的,若是任何一个操做被卡主,则后续的操做都不会被完成.
那么后续主库的 latest checkpoint location 的进度将中止,不管你作任何的操做,或者使用checkpoint 命令 也不会影响
这里若是PG_WAL 没法进行checkpoint 则代表PG的WAL LOG 没法归档,随着主库的操做愈来愈多,则WA了的文件也会愈来愈大,没法进行清理.
下面咱们在从库中将自行添加的记录删除后,在看主库的checkpoint location
已经变化了.
固然如何监控replication logical 复制是否中断的问题
select pid, client_addr, state, sync_state,
pg_wal_lsn_diff(sent_lsn, write_lsn) as write_lag,
pg_wal_lsn_diff(sent_lsn, flush_lsn) as flush_lag,
pg_wal_lsn_diff(sent_lsn, replay_lsn) as replay_lag
from pg_stat_replication;
若是你当前有一个replication 的状况下, 查询主库,若是复制正常,则会查出你与subscription之间的状况, 若是数据不一致,形成复制中止的状况,则再次查询就不会有数据显示了. 因此这也是一个判断逻辑复制是否正常的一个方式方法.
逻辑复制中止会形成主库的wal 没法截断的问题,因此若是PG 已经使用了逻辑复制,则必须对逻辑复制进行监控,不然在繁忙的业务系统中,逻辑复制的中止,会让你的主库的wal 空间出现问题,最终致使主库磁盘空间耗尽的问题.
本文分享自微信公众号 - AustinDatabases（AustinDatabases）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。