PostgreSQL 逻辑复制数据不一致,导致主库wal log 无限增大__PostgreSQL heap TABLE AM引擎，使用多版本来解决快照问题，版本处于当前数据文件中，有垃圾回收进程进行回收，那么哪些垃圾不能被回收呢？ WAL是PG的REDO文件，哪些WAL不能被回收重复利用？什么情况下可能会一直增长不清理呢？_

PG中文社区 /

mdi-home

首页

社区新闻

中文文档

加入ACE

mdi-home

首页

mdi-chat-processing

社区新闻

mdi-book-open-variant

中文文档

mdi-account-multiple-check

加入ACE

mdi-file-multiple-outline

相关资料

mdi-blank

mdi-exit-to-app

退出账号

PostgreSQL 逻辑复制数据不一致,导致主库wal log 无限增大

原作者：carol11　　创作时间：2020-09-01 21:18:44+08　　

wangliyun 发布于2020-09-02 08:00:00　　

评论: 0　　

顶: 505　

踩: 416　

### **本文转载自公众号AustinDatabases**
#### PostgreSQL的逻辑复制对比物理复制的好处总结有以下几点

#### 1 灵活: 逻辑复制对比物理复制来说,可以单表进行数据的复制,物理复制则是不可以的,并且大部分时间对于ETL的功能需求来说,物理复制太重了,需要的磁盘,网络,等资源都相对于逻辑复制消耗的要大的多.

#### 2 方便:逻辑复制相对于物理复制,设置会更简单,可以随时终止或者创建,数据进行同步等等.

#### 3 定制化:逻辑复制可以设置复制的操作,例如只需要进行insert 的复制,或者 update, delete 等操作的复制,可以做到, 数据不和primary端一致,而达到某些目的.

#### 4 数据迁移,PG如果版本不同进行升级的情况下,PG的logical replication 是可以作为一种数据迁移的方案,在不同的版本中进行数据的同步使用的.

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2123_图片1--2020.9_.1_.jpg)

#### 逻辑复制还是使用物理复制架构实现,从上图可见, 在复制槽的基础上添加了pgoutput plugin 将原有的wal 日志转换后发送, subscription 在接受这些信息,将信息填充到目的地. 为了避免数据被重复的在subscription 上重复操作,通过客户端记录接受的LSN号码,避免重复接受同样的数据,并操作.

#### 另外需要提示的是,很多不能进行vacuum的案例中,部分都有复制槽的出现,可能这个复制槽一主多用,同时有数据接收端,其中如果有数据接收端无法接受数据,则与相关的需要保留的tuples 就不会被清理,造成 vacuum 无法回收.
#### 下面我们有一个复制槽

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2125_图片2--2020.9_.1_.jpg)

#### 然后我们人为的制造一个冲突. 在数据复制的从库,将数据表的人为添加了一条数据.

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2125_图片3--2020.9_.1_.jpg)

#### 在subscription 端查看subscription 的信息

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2126_图片4--2020.9_.1_.jpg)

#### 然后我们在publication 端也插入数据

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2127_图片5--2020.9_.1_.jpg)

#### 直接进入到subscription 中查看错误日志

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2128_图片6--2020.9_.1_.jpg)

#### 系统一直在报错的状态中, 由于主库和从库之间的数据操作冲突,导致从主库到从库的数据无法被操作. 那到底是怎么影响了WAL log

#### 我们继续往下看
#### 在主库我们将2000条数据删除1900条

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2128_图片7--2020.9_.1_.jpg)

#### 在subscription 中我们查看当前的数据,结果一定是和主库已经脱离,不会在继续进行任何操作,主要的原因也是 逻辑复制是有顺序的,如果任何一个操作被卡主,则后续的操作都不会被完成.

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2130_图片8--2020.9_.1_.jpg)

#### 那么后续主库的 latest checkpoint location 的进度将停止,无论你做任何的操作,或者使用checkpoint 命令 也不会影响

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2130_图片9--2020.9_.1_.jpg)

#### 这里如果PG_WAL 无法进行checkpoint 则表明PG的WAL LOG 无法归档,随着主库的操作越来越多,则WA了的文件也会越来越大,无法进行清理.

#### 下面我们在从库中将自行添加的记录删除后,在看主库的checkpoint location 
#### 已经变化了.

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2131_图片10--2020.9_.1_.jpg)

#### 当然如何监控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;

![CENTER_PostgreSQL_Community]( /images/news/2020/20200901_2132_图片11--2020.9_.1_.jpg)

#### 如果你当前有一个replication 的情况下, 查询主库,如果复制正常,则会查出你与subscription之间的情况, 如果数据不一致,造成复制停止的情况,则再次查询就不会有数据显示了.  所以这也是一个判断逻辑复制是否正常的一个方式方法.

#### 逻辑复制停止会造成主库的wal 无法截断的问题,所以如果PG 已经使用了逻辑复制,则必须对逻辑复制进行监控,否则在繁忙的业务系统中,逻辑复制的停止,会让你的主库的wal 空间出现问题,最终导致主库磁盘空间耗尽的问题.

![CENTER_PostgreSQL_Community](/images/news/2016/pg_bot_banner.jpg)

评论:0　　

顶: 505　

踩: 416　

请在登录后发表评论，否则无法保存。