从持续贡献到逻辑复制改进：Fujitsu 如何参与塑造 PostgreSQL 19

2026-07-28 27 预计阅读时间: 1 分钟
来源: postgr.es AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

PostgreSQL 19 的演进不只来自某个单独功能，也依赖企业工程团队长期参与补丁开发、代码审查和社区协作。Fujitsu 的 PostgreSQL 团队通过持续提交代码、获得社区认可，并推动逻辑复制相关改进，进一步扩大了其在 PostgreSQL 开源生态中的影响。

由于摘要没有列出具体补丁名称和最终合入状态，本文不会把尚未明确的细节写成既定功能，而是重点分析这种贡献模式对数据库团队意味着什么，并给出一套可以实际运行的逻辑复制验证方法。

企业贡献的价值不只是一组补丁

企业参与开源数据库开发时，最容易量化的是提交数量，但真正影响 PostgreSQL 核心质量的工作远不止编写代码。一个改动从构想到进入正式版本，通常还要经历设计讨论、测试补充、性能验证、跨平台检查和多轮代码审查。

Fujitsu 团队对 PostgreSQL 19 的持续投入至少体现了三个层面的价值：

  • 工程连续性：数据库内核改动往往跨越多个开发周期，稳定投入比一次性提交更重要。
  • 社区协作：PostgreSQL 采用社区驱动的开发模式，补丁必须接受公开讨论和审查。获得社区认可，意味着贡献不仅解决局部需求，也符合项目整体方向。
  • 生产经验反馈：长期运行大型数据库系统的团队，能够把可运维性、故障恢复和性能边界等现实问题带入内核开发。

这也说明，衡量一家企业对 PostgreSQL 的影响时，不能只看是否开发了醒目的新特性。审查其他开发者的补丁、完善回归测试、定位边界条件，同样可能决定一个版本能否可靠发布。

为什么逻辑复制值得持续改进

物理流复制传输的是 WAL 所描述的底层数据页变化，适合同构集群中的高可用和灾难恢复。逻辑复制则面向表和行级变更，订阅端可以选择接收哪些数据，因此更适合以下场景：

  • 按表拆分数据分发范围；
  • 构建跨环境的数据同步链路；
  • 为版本升级准备并行迁移路径；
  • 将业务数据发送到报表或集成系统；
  • 在不复制整个实例的情况下建立只读数据副本。

逻辑复制的灵活性也带来了更多边界条件。表结构需要协调，主键和复制标识会影响 UPDATE、DELETE 的传播，初始数据复制可能与持续写入竞争资源，网络中断后还需要正确续传。因此，围绕逻辑复制的内核改进通常会直接影响迁移风险和日常运维成本。

摘要只确认 Fujitsu 参与了 PostgreSQL 19 的逻辑复制改进，没有给出具体功能清单。在评估 PostgreSQL 19 时，应以正式发行说明、提交记录和对应文档为准，避免依据预览信息修改生产架构。

动手建立一条最小逻辑复制链路

下面的实验展示逻辑复制的基本工作流，可以用于搭建后续测试基线。示例使用两个 PostgreSQL 实例：发布端监听 5432，订阅端监听 5433。命令适用于支持内置逻辑复制的 PostgreSQL 版本；测试 PostgreSQL 19 时，需要使用对应的开发版或正式发行包，并再次核对参数和文档。

先在发布端启用逻辑复制所需配置：

# publisher/postgresql.conf
wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
listen_addresses = 'localhost'

允许本机订阅端以复制用户连接。请根据实际数据库、网段和认证策略调整，不要直接照搬到生产环境：

# publisher/pg_hba.conf
host    appdb       replicator    127.0.0.1/32    scram-sha-256

重启发布端后，创建数据库对象、复制用户和 publication：

psql -h localhost -p 5432 -U postgres <<'SQL'
CREATE ROLE replicator WITH LOGIN REPLICATION PASSWORD 'change-me-now';
CREATE DATABASE appdb;
SQL

psql -h localhost -p 5432 -U postgres -d appdb <<'SQL'
CREATE TABLE orders (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_name text NOT NULL,
    total_cents integer NOT NULL CHECK (total_cents >= 0),
    created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO orders (customer_name, total_cents)
VALUES ('Ada', 2599), ('Linus', 4800);

CREATE PUBLICATION app_publication FOR TABLE orders;
GRANT CONNECT ON DATABASE appdb TO replicator;
GRANT USAGE ON SCHEMA public TO replicator;
GRANT SELECT ON TABLE orders TO replicator;
SQL

在订阅端创建结构相同的表，再建立 subscription。内置逻辑复制不会自动替你完成所有 DDL 变更，因此显式维护兼容结构很重要：

psql -h localhost -p 5433 -U postgres <<'SQL'
CREATE DATABASE appdb;
SQL

psql -h localhost -p 5433 -U postgres -d appdb <<'SQL'
CREATE TABLE orders (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_name text NOT NULL,
    total_cents integer NOT NULL CHECK (total_cents >= 0),
    created_at timestamptz NOT NULL DEFAULT now()
);

CREATE SUBSCRIPTION app_subscription
CONNECTION 'host=localhost port=5432 dbname=appdb user=replicator password=change-me-now'
PUBLICATION app_publication;
SQL

插入一条新记录并检查订阅端：

psql -h localhost -p 5432 -U postgres -d appdb \
  -c "INSERT INTO orders (customer_name, total_cents) VALUES ('Grace', 7300);"

psql -h localhost -p 5433 -U postgres -d appdb \
  -c "TABLE orders;"

生产系统不要把密码直接写入命令历史或 subscription 连接字符串管理脚本。可以使用 .pgpass、受权限保护的配置文件或平台提供的密钥管理服务，并限制复制账号只能访问需要发布的对象。

用可观测数据评估复制质量

“数据最终出现了”只能证明基本链路可用，还不足以评估升级或生产部署。可以在发布端查看复制槽状态：

SELECT slot_name,
       slot_type,
       active,
       restart_lsn,
       confirmed_flush_lsn
FROM pg_replication_slots;

在订阅端查看订阅工作进程：

SELECT subname,
       worker_type,
       pid,
       received_lsn,
       latest_end_lsn,
       latest_end_time
FROM pg_stat_subscription;

不同 PostgreSQL 版本的系统视图列可能存在变化，执行前应查阅目标版本文档。测试时至少记录以下指标：

  • 初始表同步耗时和对源库的负载影响；
  • 持续写入期间的复制延迟；
  • 订阅端停机后，发布端 WAL 和复制槽占用的增长速度；
  • 大事务、批量更新和 DELETE 的处理表现；
  • DDL 变更前后的兼容性；
  • 网络中断、进程重启和磁盘空间不足后的恢复行为。

尤其要关注失活复制槽。订阅端长时间离线时，发布端可能为了复制槽持续保留 WAL，最终消耗大量磁盘空间。逻辑复制方案必须同时配备延迟监控、容量告警和复制槽处置流程。

采用 PostgreSQL 19 前的检查清单

Fujitsu 对 PostgreSQL 19 的贡献说明，成熟企业可以通过长期社区协作直接推动开源数据库能力演进。但对使用者而言，贡献者背景不能代替版本验证。

准备采用 PostgreSQL 19 时，可以按以下顺序推进：

  • 阅读正式发行说明，确认逻辑复制改进的准确范围和兼容性要求；
  • 在与生产接近的数据量、事务模式和网络条件下建立基准；
  • 验证表结构变更、复制标识、权限和序列处理策略；
  • 为复制槽、WAL 积压、订阅错误和延迟建立监控；
  • 设计可回退的升级与切换流程，不把逻辑复制本身当作完整回滚方案；
  • 在正式切换前演练断网、订阅端故障和长事务等异常场景。

PostgreSQL 的稳定演进来自贡献者、审查者和用户之间的长期反馈循环。Fujitsu 在 PostgreSQL 19 中不断扩大的参与度，值得关注的不只是某项特性，更是企业生产经验进入开源数据库核心开发的方式。

# AI # Go # PostgreSQL # 后端 # 数据库

相关推荐