PG的复制

pg的解码器

解码器是把WAL日志解析成逻辑数据的过程，将用户定阅的数据变化（即对某些表的insert/update/delete操作来带的数据变化）输出成特定的数据格式

decoderbufs

需要安装一堆插件,在centos上非常难于安装,官方给出的例子也是基于debein操作系统

wal2json

debezium对wal2json的支持不好,他自己官网说的

pgoutput

postgres-10 纳入了内核 以下为pgoutput解析出来的逻辑数据
连接为

复制

pg即可以逻辑复制,也可以物理复制 没有互斥

物理复制

物理层面、逻辑层面完全一致：主备数据库的物理块完全一样，逻辑层面也 完全一样，达到金融级需求。特点如下:

• 延迟极低：任何大事务，主库完成提交，备库能立即提交。事务过程中产生的每条record会实时同步到备库进行回放，因此，备库不会因为回放大事务而使得延迟很大 (我的理解同步的也就是一个commit语句的操作,延迟极低)
• 粒度粗 整个实例级别同步：物理复制针对整个实例进行同步，无法仅针对单个表或者数据库进行同步
• 粒度粗 同步级别无法单独设置：数据库同步级别针对整个流复制，无法针对某个表进行设置流复制级别
  场景一:
  往往一个数据库中，仅有几张最重要表需要*别的同步等级，其他表异步即可 这个物理复制是做不到的 比如日志表不需要很高的同步等级

逻辑复制(叫发布端与订阅端)

2017年逻辑复制发布到pg10的内核,作为PG的重要特性基于REDO流,之前内核没有时大家都是基于pglogical插件来做

不叫主从复制了,是发布订阅方式实现逻辑复制达到同步数据

• 同步的最小单元为表,比较灵活
• 可设置不同的同步级别,可以配置很高的同步等级,及异步等级
• 支持多对一、- -对多、多对多进行逻辑复制， 以能够很灵活的实现各种同步需求。即linux到windows的逻辑复制
  场景多对一 多个PG往一个PG上汇总数据
  场景一对多 一个用户表往多个应用库的表分发用户信息
• 订阅端也可以再次写数据,然后再次对数据表进行发布

逻辑复制架构图

上图的订阅断可以为一个pg也可以为kafka连接器伪造一个订阅断

槽位replication slots

replication slots 是从postgresql 9.4 引入的,一种自动化的方法来确保发布与订阅 如果备掉线了,slots会申请保留WAL的日志造成堆积,还有就是 订阅断存在冲突的记录时,他会同样申请WAL保留相应日志
坑就是会造成wal日志堆积,进而影响整库性能,最终造成崩溃

通俗的说:
复制槽 能够保存逻辑或物理流复制的基础指向WAL日志的信息,有点儿MySQL的位点信息的意思 可以暂时这么理解

业界关注的问题

问题:
逻辑流复制用上事务槽，如果事务槽不释放导致wal慢的情况可能把库跟搞死了，这个怎么解决哈
回答 这个就要注意，因为如果很久没有回放，就会导致wal日志堆积
追加:
1）避免长事务，一般超过1天的事务理论上都可以取消掉的。
2）防止复制节点掉线，如果掉线了，slot就会保留他们需要的wal日志。
-------------------------------------------------------
3）如果上面的方法有难度，就可以考虑不走slot，把keep_wal_segments设置大一点
4）针对物理流复制，还可以开启归档，不走slot，从归档中异步同步数据。

逻辑复制搭建

一个发布端pg一个订阅断pg
debezium
pglogical

逻辑复制–发布端配置

修改主库的postgresql.conf

wal_level=logical
max_wal_senders=10
max_replication_slots=8

逻辑复制使用注意

ddl同步搞定不了 debizum能搞定
建表得有replicatoin标识否则删除数据时报错

本文地址：https://blog.csdn.net/maqingbin8888/article/details/107578228