逻辑复制 on Kernel Notes

PostgreSQL 3-13 逻辑复制原理与性能优化

Mon, 29 Dec 2025 20:38:00 +0800

1 基本概念

1.1 业务场景

场景一：数据共享（异构数据库）
1个公司，有2个部门：商品库存部门、商品成本部门。2个部门有不同技术栈，使用不同数据库产品:postgresql、mysql。2个部门需共享相同的表：商品信息表。
场景二：数据容灾
应用存储数据时，同时将数据存储至postgresql于mysql中，避免某款数据库出现无法恢复的数据损坏问题。
场景三：版本升级
从postgresql 13版本，升级到postgresql 16版本。
场景四：数据迁移（异构数据库）
从postgresql，将数据库迁移到mysql中。

PostgreSQL 3-13 Vastbase 逻辑复制

Thu, 27 Nov 2025 19:07:00 +0800

2 使用

2.1 发布端

配置

# vb
echo "wal_level=logical" >> $GAUSSHOME/data/postgresql.conf
echo "max_replication_slots=4" >> $GAUSSHOME/data/postgresql.conf
echo "max_wal_senders=4" >> $GAUSSHOME/data/postgresql.conf
# echo "max_worker_processes=8" >> $GAUSSHOME/data/postgresql.conf
echo "max_logical_replication_workers=32" >> $GAUSSHOME/data/postgresql.conf

echo "listen_addresses='*'" >> $GAUSSHOME/data/postgresql.conf

sed -i '1i host all all 0.0.0.0/0 md5\n' $GAUSSHOME/data/pg_hba.conf
echo "host replication all 0.0.0.0/0 md5" >> $GAUSSHOME/data/pg_hba.conf
# host all all 0.0.0.0/0 md5

psql -d postgres -c "SELECT name,setting FROM pg_settings WHERE name in
 ('wal_level', 'max_replication_slots', 'max_wal_senders', 'max_worker_processes', 'max_logical_replication_workers')"

创建基表

CREATE DATABASE pubdb;
\c pubdb
CREATE TABLE pt1(c1 INT,c2 TEXT);
CREATE TABLE pt2(c1 INT, c2 TEXT);
INSERT INTO pt1 VALUES (1,'data1-1'), (2,'data1-2');
INSERT INTO pt1 VALUES (1,'data2-1'), (2,'data2-2');

创建发布用户

PostgreSQL 3-13 逻辑复制性能优化

Fri, 21 Nov 2025 15:18:00 +0800

2025-11-21：持续更新中…

1 需求概述

1.1 原始需求

主备部署模式下，滚动升级时，可能存在主节点未升级，备节点已升级的情况。在该条件下，客户要求主节点持续执行事务，并且主节点及时将数据同步至备节点。目前，存在一下问题：

物理复制无法使用：由于主节点、备节点版本不一致，主节点生成的wal，备节点可能无法使用。因此，只能使用逻辑复制方案。
逻辑复制性能较低：主节点作为发布端，解码wal。备节点作为订阅端，接收loggic-wal，并且回放logic-wal，可解决主备版本不一致的问题。但是，目前Vastbase的逻辑复制功能性能较低，无法满足及时同步数据的要求。

本需求将针对上述场景，端到端优化逻辑复制功能，让逻辑复制性能整体提升5倍以上，达到100m/s的要求。

需求来源：https://doc.weixin.qq.com/doc/w3_AYsAjQYkADwCNecwqsBM8ShS9YejB?scode=AHUAfwdSAA8UDeKla8AdwAfAa7AFk&roomid=Person%3A1688855660690652%3A1688855164259723&version=5.0.2.6008&platform=win

1.2 问题分析

逻辑复制分为多个阶段，openGauss和PostgreSQL在部分阶段中做了优化，但未端到端优化。因此，本文将以早期逻辑复制为基础，指出优化设计。

版本一：串行复制

在postgresql 13以及之前版本，逻辑复制的关键设计如下：

发布端：
- 解码日志：wal-sender进程，持续读取wal，串行对wal进行decode，生成logic-wal，并将不同事务的logic-wal，分别存放。
- 发送日志：对wal进行decode时，如果是事务提交产生的wal，则将该事务的所有logic-wal打包，并发送到订阅端。
订阅端：
- 回放日志：apply-worker进程，一次接收同一事务的一批logic-wal，串行回放本批logic-wal后，重新等待下一个事务的logic-wal。

整体方案如下：

以上设计，存在多项性能瓶颈，以常见的tpcc测试为例，可能有400+postgres进程在执行事务，实时产生wal日志。但是，只有1个wal-sender进程在串行解码日志，只有1个apply-workder在串行回放日志。

1.3 方案设计

版本二：发布端并行解码

在openGauss中，针对发布端的解码日志阶段，进行了优化，引入多个decoder线程，并行解码wal生成logic-wal。方案设计如下：

但是，在订阅端，每次对一个事务的一批logica-wal全部回放后，才会接收下一个事务的logic-wal。仅引入并发解码机制，对性能提升较小。发布端和订阅端，均存在负载不均衡的问题，例如，订阅端回放完一个事务的logic-wal之后，需等待下一个事务的logic-wal。

版本三：流氏复制协议

在postgrsql 14版本，针对发布端发送日志阶段，进行了优化，引入流式复制协议，即无需一次发送完一个事务完整的一批logic-wal，而是随时发送logic-wal，即使事务未提交。可解决发布端、订阅端负载不均衡的问题。

但是，在订阅端，tpcc场景，发布端400+postgres进程执行事务，订阅端1个apply-worker进程回放日志，仍是瓶颈。

版本四：订阅端并行回放

在postgrsql 16版本，针对订阅端回放日志阶段，进行了优化，引入多个apply进程，并行回放logic-wal。方案设计如下：

版本五：并行复制

结论：本需求参考性能测试结果，认为需同时结合：并行解码、流式复制、并行回放机制，才能提升逻辑复制端到端性能。
优先级：其中，流式复制、并行回放机制，对性能影响较大，优先级较高。可独立地、优先地实现。
其他工作：同时采用上述3个机制，需合理控制发布端解码速率、订阅端回放速率，在实现负载均衡的同事，避免logic-wal堆积。

2 设计分析

2.1 必要性

根据postgrsql-16的性能测试结果，流式复制和并行回放机制，可达到70Mb/s的复制速度。

一、测试场景

测试机器：
- IP：172.16.103.90
- 硬件：CPU：鲲鹏920-ARM-128核。缓存L1-L2-L3：8M/64M/256M。内存：760G。磁盘：NVME
- 系统：openEuler
tpcc测试场景（为了快速测试，不太标准）
- 数据量：100 warhouse
- 并发：400
- 执行时间：1 min
逻辑复制配置：
- 部署：发布端、订阅端在同一台机器（找不到2台性能机）
- 订阅：创建1个publiction，涵盖所有table

二、测试数据

由于机器、时间等限制，测试未严格控制变量，但是，和准确结果应该有80%以上符合度。

版本	配置	tpmc	发布端-wal写入速度	逻辑复制速度（峰值）	逻辑复制速度（平均值）
postgrsql-14	串行解码、非流式复制、串行回放	约65w	207 Mb/s	-	16 Mb/s
postgresql-16	串行解码、流式复制、串行回放	约65w	212 Mb/s	117 Mb/s	55 Mb/s
postgresql-16	串行解码、流式复制、并行回放(4)	约65w	197 Mb/s	113 Mb/s	71 Mb/s

测试：贾旭辉

详细数据和结论见wiki：https://www.tapd.cn/60475194/markdown_wikis/show/#1160475194001007526

尝试修改源码，让订阅端只接受日志，不apply，确定发布端解码和发送的瓶颈，但是，测试结果有点奇怪，有空再继续。

2.2 可行性

并行解码：openGauss已引入
流式复制：postgreql-16版本已成熟
并行回放：postgreql-16版本已成熟

2.3 潜在风险

一、数据有一致性

写写冲突

PostgreSQL 3-13 Publication

Thu, 28 Aug 2025 16:18:00 +0800

1 逻辑复制背景

1.1 逻辑复制场景

在使用数据库时，为提高整个系统的可靠性，或实现不同部门数据同步等场景，很多客户的部署模型存在：一主多备、异构数据库等特点，在保证性能的前提下，常见部署模型如下：


+-------------+ sql +---------------------+ wal +--------------------+
| application | --------> | postgresql (master) | -------> | postgresql (slave) |
+-------------+ +---------------------+ +--------------------+
 |
 |
 | decoded-wal +--------------------+
 +---------------------> | mysql, oracle, .. |
 +--------------------+

1.2 逻辑复制功能

1.3 逻辑复制基础

首先，需自行了解一些存储的基本知识，包括事务特性、mvcc机制，表的物理存储格式：filenode、page、tuple等。
此处，以一个例子，介绍什么wal日志的特点。需了解一些

应用执行事务
假设同一时间，有2个事务，事务id分别为10和11。

时间	应用1	应用2
0	CREATE TABLE t1 (c1 INT,c2 INT)	-
1	CREATE TABLE t2 (c1 INT,c2 INT)	-
2	BEGIN (xid=10)	-
3	INSERT INTO t1 VALUES(10, 1)	-
4	-	BEGIN (xid=11)
5	-	INSERT INTO t1 VALUES (11, 1)
6	INSERT INTO t2 VALUES (10, 2)	-
7	COMMIT
8	-	DELETE FROM t1 WHERE c1 = 10
9	-	INSERT INTO t2 VALUES (11, 2)
10	-	COMMIT

内核产生wal日志
所有表的wal日志，按生成wal的顺序，组织在一起。上述示例中，产生的wal如下：（此处仅列举关键信息）

海量 11 需求逻辑复制性能优化

Fri, 06 Feb 2026 14:30:00 +0800

1 简介

1.1 目的

逻辑复制是一种在多个数据库实例之间复制数据的功能，通常用于从一个数据库实例中，将针对指定表的insert、delete、update等写操作，复制到其他另一个数据库实例。在数据库术语中，统一称逻辑复制的发送方为发布端，称接收方为订阅端。Oracle、Postgresql、Vastbase等数据库产品，均提供逻辑复制功能。

当前版本，逻辑复制性能较低，以tpcc场景为例，发布端40w tmpc时，订阅端的复制速度约10m/s。在滚动升级等场景，通过逻辑复制在不同实例间同步大量数据，要求逻辑复制性能达到70-100m/s。

发布端、订阅端均存在性能瓶颈，均需要优化。但是，由于交付时间较短，以及订阅端方案仍有瑕疵等因素，本版本交付发布端性能优化，下版本交付订阅端性能优化。

1.2 适用范围

本文主要用于向开发、测试等角色，介绍G100 3.0.9 psu2及之后版本，逻辑复制的性能优化的设计方向与使用方法。

1.3 术语定义、首字母缩写词和缩略语

发布端：逻辑复制场景，发送数据方。
订阅端：逻辑复制场景，接收数据方。

1.3 参考资料

Vastbase G100产品文档中逻辑复制使用介绍：https://docs.vastdata.com.cn/zh_CN/VastbaseG100/V3.0.8/1/f5c2ae8eb9744d429ad39c02438addf6

2 G100审计功能重构

2.1 功能简述

需求背景：逻辑复制使用

使用逻辑复制的流程如下：

发布端：配置逻辑复制

# 设置wal日志详细级别，设计身份等参数，重启集群
gs_guc set -D $PGDATA -c 'wal_level=logical'
gs_guc set -D $PGDATA -h "host all all 0.0.0.0/0 md5"
gs_guc set -D $PGDATA -h "host replication all 0.0.0.0/0 md5"
vb_ctl restart -D $PGDATA

发布端：创建表

CREATE TABLE pt1(c1 INT,c2 TEXT);
CREATE TABLE pt2(c1 INT, c2 TEXT);

发布端：创建发布，即指定哪些表需复制
```
CREATE PUBLICATION pub1 FOR TABLE pt1,pt2;
```
发布端：创建逻辑复制槽，用于存储复制状态等信息

海量 15 设计逻辑复制性能优化

Wed, 06 May 2026 17:48:00 +0800

1 逻辑复制性能优化

1.1 功能简述

原理：
假设，发布端执行INSERT INTO t1 VALUES(1,'data1')，更改1行数据，产生1条wal日志。逻辑复制功能将读取这条wal，解码并生成1条message，将message发送至订阅端。订阅端应用这条message，等价于重新执行INSERT INTO t1 VALUES(1,'data1')。
问题：
308.1 psu1以及之前版本，逻辑复制性能较低。以tpcc场景为例，40w tmpc时，发布端产生wal日志速度约100m/s，订阅端的复制速度约10+m/s。
客户：
滚动升级场景中，备机停机升级，主机持续执行业务，备机升级后使用逻辑复制追赶主机数据。长存客户场景，主机产生wal日志速度约40-50m/s，旧版本逻辑复制速度10+m/s，由于逻辑复制速度太慢，备机无法追赶主机，最终导致升级失败。
优化
本需求设计与实现并行逻辑复制机制，大幅提高逻辑复制速度，在上述场景中，订阅端速度可达到70-90m/s。并行逻辑复制分为3个关键子机制：
1. 发布端多线程并行解码
2. 发布端与订阅端流复制传输协议
3. 订阅端多线程并行应用

1.2 实现方案

本章分3个章节，分别介绍3个关键子机制。

1.2.1 发布端并行解码机制

在旧版本中，发布端采用串行解码机制，只有1个walsender线程，串行执行：1次读取1条wal日志，解码1条wal生成1条message，缓存或发送message。

旧版本代码中，发布端有实现并行解码的代码，但是，无法直接使用，订阅端只能是工具，不能是数据库实例，且存在大量问题。本需求基于旧版本并行解码，实现权限的并行解码机制。

并行解码机制，将启动多个线程，包括1个reader、多个decoder、1个walsender，它们的功能如下：

reader：1次读取1条wal日志，将wal发送给decoder
decoder：1次接收1条reader发送的wal，解码生成message，将message发送给walsender
walsender：1次接收1条decoder发送的message，将message发送给订阅端

线程架构图如下：

lsn 1-10
 d1 1 4 collect 阻塞 1
 d2 2 5 2
 d3 3 6 3

1.2.2 发布端与订阅端流复制协议

一、握手阶段

订阅端与发布端建立连接时，订阅端会根据CRETE SUBSCRIPTION语法设置的参数，生成连接命令，根据连接命令，发布端和订阅端决定采用哪种通信协议，究竟是采用事务复制协议（旧版本）还是流复制协议（新版本）。

事务复制协议（旧版本）

订阅端发送的连接命令如下：

START_REPLICATION SLOT "$slot_name" LOGICAL $start_lsn
 (proto_version '3', publication_names '"$publication_name"')

流复制协议（新版本）

如果CRETE SUBSCRIPTION时，指定worker_number>1，即启用并行逻辑复制机制，将使用新的连接命令，订阅端发送的连接命令如下：

START_REPLICATION SLOT "$slot_name" LOGICAL $start_lsn
 (proto_version '3', publication_names '"$publication_name"'， streaming 'extreme', parallel-decode-num '20', max-recordbuffer-in-memory '100', max-txn-in-memory '100')

上述命令中新增了多个参数：

海量 15 需求逻辑复制性能优化

Wed, 06 May 2026 10:05:00 +0800

1 简介

1.1 目的

当前版本，逻辑复制性能较低。以tpcc场景为例，发布端40w tmpc时，产生wal日志速度约100+m/s，订阅端的复制速度约10+m/s。在滚动升级场景，主机和备机可能是不同的产品版本，主备复制数据时，不能使用物理复制，只能使用逻辑复制。在长存客户场景中，主机产生wal日志速度在50+m/s左右，备机使用逻辑复制，复制速度约10+m/s，备机将追赶不上主机进度，导致滚动升级失败。

主a 备b 备c
+-----------------------+---------------------------+-----------------------------
|1 ==>执行业务
|2 开始滚动升级，暂停流复制 lag=400M
 |3 暂停流复制（物理复制）
|4 创建逻辑复制槽 lsn1=1G
 |5 恢复流复制
 |6 物理复制追赶，到逻辑复制槽
 |6 开始单节点升级
 |7 [升级] 停止进程
 |8 [升级] 替换二进制等
 |9 [升级] 启动进程
 |10 单节点升级成功
|11 持续执行业务 lsn2=2G
 |12 创建订阅，启动逻辑复制，lsn1=1G
 |13 逻辑复制开始追赶（初始差距：lsn2-lsn1)
|14 持续执行业务 lsn3=2.5G
 |15 逻辑复制持续追赶 lsn=1.6G
|16 (可重置lag)
 |17 差距持续缩小（从lsn2-lsn1降低到lag）
|18 发送停机命令
|19 停止业务
 |20 差距持续缩小，从lag缩小至0
|21 停止进程成功

因此，需大幅提高逻辑复制速度，在长存客户场景中，逻辑复制速度至少需达到70+m/s。目前，发布端、订阅端均存在性能瓶颈，均需要优化。

1.2 适用范围

G100 3.0.9 psu2及之后版本

1.3 术语定义、首字母缩写词和缩略语

发布端：逻辑复制场景，发送数据方。
订阅端：逻辑复制场景，接收数据方。

1.4 参考资料

Vastbase G100产品文档中逻辑复制使用介绍：https://docs.vastdata.com.cn/zh_CN/VastbaseG100/V3.0.8/1/f5c2ae8eb9744d429ad39c02438addf6
oracle goldengate并行复制：https://oracle.hydrogen.sagittarius.connect.product.adaptavist.com/en/database/goldengate/core/26/coredoc/replicat-parallel-replicat.html#GUID-F1CD8E03-8DA1-4A78-95D3-C0516F1DA09A

2 逻辑复制性能优化

2.1 功能简述

一、逻辑复制使用示例

使用逻辑复制，可概括为3个阶段：

逻辑复制 on Kernel Notes

PostgreSQL 3-13 逻辑复制原理与性能优化

目录

1 基本概念

1.1 业务场景

PostgreSQL 3-13 Vastbase 逻辑复制

2 使用

2.1 发布端

PostgreSQL 3-13 逻辑复制性能优化

1 需求概述

1.1 原始需求

1.2 问题分析

版本一：串行复制

1.3 方案设计

版本二：发布端并行解码

版本三：流氏复制协议

版本四：订阅端并行回放

版本五：并行复制

2 设计分析

2.1 必要性

一、测试场景

二、测试数据

2.2 可行性

2.3 潜在风险

一、数据有一致性

PostgreSQL 3-13 Publication

1 逻辑复制背景

1.1 逻辑复制场景

1.2 逻辑复制功能

1.3 逻辑复制基础

海量 11 需求 逻辑复制性能优化

1 简介

1.1 目的

1.2 适用范围

1.3 术语定义、首字母缩写词和缩略语

1.3 参考资料

2 G100审计功能重构

2.1 功能简述

需求背景：逻辑复制使用

海量 15 设计 逻辑复制性能优化

1 逻辑复制性能优化

1.1 功能简述

1.2 实现方案

1.2.1 发布端并行解码机制

1.2.2 发布端与订阅端流复制协议

一、握手阶段

事务复制协议（旧版本）

流复制协议（新版本）

海量 15 需求 逻辑复制性能优化

1 简介

1.1 目的

1.2 适用范围

1.3 术语定义、首字母缩写词和缩略语

1.4 参考资料

2 逻辑复制性能优化

2.1 功能简述

一、逻辑复制使用示例

海量 11 需求逻辑复制性能优化

海量 15 设计逻辑复制性能优化

海量 15 需求逻辑复制性能优化