云数据库产品应改造PostgreSQL逻辑复制槽缺陷--来自真实企业的需求-CSDN博客

本文链接：https://blog.csdn.net/liuhuayang/article/details/148728393

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3000人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 150+，将开10群)

最近在使用PostgreSQL中遇到一些问题，主要集中在逻辑复制槽的部分，在大型企业使用PostgreSQL中会遇到一个核心的问题，数据的传递和流转的问题，大部分使用PostgreSQL的公司，最终使用的技术都是逻辑复制槽方式。

在更大量的数据传递的过程中，我们遇到的最大的问题就是逻辑复制槽的延迟，给系统给业务带来危害和业务损失的问题，这里进行阐述，希望基于POSTGRESQL研发的国产数据库或RDS，云原生数据库厂商能解决POSTGRESQL的逻辑复制槽的问题。

问题的阐述：

多个逻辑复制槽并用的问题。

PostgreSQL 数据库可以支持多个逻辑库，一个逻辑库是订阅的最大单位，这里需要注意逻辑库的数量，逻辑库的数量增多，订阅逻辑复制槽的数量会同时提高，这非常不利于系统的运行和安全，尤其在数据库系统有多个逻辑订阅者的情况下。于此同时我们还存在其他的需求，比如A客户要30张表，B客户要60张表，他们虽然在一个逻辑库，但是他们要的表不同，我就需要建立两个逻辑复制槽分别对这些表进行输出，产生至少两个订阅，这就导致逻辑复制槽的数量在业务复杂性提高的同时，会远远高于逻辑库的数量。

逻辑复制槽问题梳理

问题就产生了

1 一个订阅者，拥有一个逻辑复制槽，也就是说即使两个订阅者需要的数据是一致的，但是他们的目的不同，就需要建立两个逻辑复制槽

2 当多个订阅者由于订阅的消费WAL数据的速度不同，会导致由于一个订阅者的消费速度慢而影响整个数据库的WAL的存储造成WAL的堆积

3 一个数据库实例，有多个逻辑库，每个逻辑库一个订阅，这样的情况下订阅的数量也很大，会造成内存和CPU的消耗异常，逻辑复制槽本身限制PG数据库的数据流转的性能和便利性

4 在PG数据库进行切换的过程中，并不带有逻辑复制槽转移的功能，这里需要在新的库上重建逻辑复制槽，这点在很多企业中是无法接受，虽然通过patroni的方案可以进行切换后，逻辑复制槽的重建，但这也并非一个完美的解决方案，每次建立逻辑复制槽失效，在重建逻辑复制槽对于应用部门都是不能被接受的。

5 重复的数据流转的目的地不同，导致多个订阅，最终导致网络流量和数据带宽的超量使用的问题。

建议基于POSTGRESQL厂商开发出一种新的模式来支援POSTGRESQL逻辑复制槽的部分，可以作为一个新的中介使用，方案如下。

逻辑复制槽和订阅新方式

这里假设，数据库软件公司开放出一套中间件，通过中间件安装在一台主机中，PG 只需要建立一个物理复制槽的方式来将数据全量同步到中间件，中间件再通过自身的方式给其他的数据订阅方数据。

在目前没有厂商进行优化方案产生的情况下，可以采用从库提供逻辑复制槽的方式来减轻主库的压力，具体方案如下

1 使用POSTGRESQL16版本， wal_level= logical ,从库必须启用 hot_standby_feedback=on, 在主库通过物理复制槽的方式给付从库数据，实际上就是石红data streaming的方式，给付物理的数据流给从库。

从库上进行 pg_create_logical_replication_slot的逻辑复制槽的建立，来隔绝主库所承受的的压力和风险。

+----------------+
             |    主库 PG     |
             | 写操作         |
             +--------+-------+
                      |
           (物理复制槽, streaming replication)
                      |
             +--------v--------+
             |    从库 PG      |
             | hot_standby     |
             +---+----------+--+
                 |          |
 (逻辑复制槽)     |          | (逻辑复制槽)
                 |          |
        +--------v--+   +---v--------+
        | Debezium  |   |  PG订阅者   |
        |  + Kafka  |   |  子系统B    |
        +-----------+   +------------+

产品设计，在大型企业中使用PostgreSQL 逻辑复制槽的应用需求越来越多，而PostgreSQL逻辑复制槽功能本身存在很多的应用问题，比如上面提到的资源消耗过多，这里我们以ORACLE的LogMiner作为比对对象，虽然Oracle并未提供如不消费日志就不删除日志的功能，相对PostgreSQL对于应用是友好的，可我们需要更灵活的处理方式，让用户可以设置在特殊情况下，直接选择抛弃日志，保证磁盘空间的安全设置，避免由于逻辑复制槽不消费，或消费慢导致的日志挤压后的磁盘空间满了后的数据库运行系统的风险。

同时我们希望PostgreSQL能提供如ORACLE可以设置对外重放日志的时间段的设置，方便数仓在无法追上后的继续增量数据的补偿和跳过后的继续读取日志中的数据的能力。

所以这里建议一些云厂商，针对PostgreSQL在逻辑复制槽中的缺陷问题，予以重视。开发出更适合多逻辑库，多复制槽输出数据的高性能场景的支持，方便大型上云的企业，更好更方便的使用PostgreSQL 在大型企业Saas类的应用场景的需求满足。