2026年8月8日 2 分钟阅读

PostgreSQL 的 WAL 越积越大时:用 Redpanda Connect 把 CDC 做成可观测的数据管道

tinyash 0 条评论

把 PostgreSQL 的订单、用户或审计记录送到消息系统,常见的起点是“订阅数据库变更”。但真正上线后,问题很快会从能否读到一条更新,变成更工程化的几件事:初始存量如何导入;数据库日志何时可以回收;下游不可用时是否会悄悄漏数据;以及容器编排系统如何区分进程活着和管道已经可用。

Redpanda Connect 是一个用 YAML 描述拓扑的流处理器,能够连接多种输入、处理器和输出。它支持 PostgreSQL 等数据库的 CDC 连接器,也能把数据发往 Redpanda 兼容的 Kafka API。本文以“一个 PostgreSQL 表的变更进入主题”为例,重点不是堆叠更多中间件,而是把复制前提、确认链路和运维探针明确写出来。

需要先说明许可边界:Redpanda Connect 仓库的大多数连接器与功能采用 Apache-2.0;企业功能采用 Redpanda Community License(RCL)。本文使用的 postgres_cdc 组件在当前官方文档中标注需要企业许可证或 30 天试用许可证,因此不能把这套方案笼统称为“全开源、零许可成本”的 CDC 组合。选型前应先确认部署版本和许可,而不是等到生产配置完成后才发现连接器不可用。

先理解:CDC 读的不是业务表,而是 WAL 的复制流

postgres_cdc 使用 PostgreSQL logical replication(逻辑复制)捕获实时变更。连接建立后,它会创建 replication slot,并通过 WAL(Write-Ahead Log,预写日志)订阅记录变化。这个机制有两个直接后果。

第一,数据库必须满足前置条件。官方文档要求 PostgreSQL 14 或更高版本,并启用 logical replication。最小的自检不是先启动连接器,而是登录数据库确认:

SHOW wal_level;

结果应为 logical。对于自托管 PostgreSQL,如果还要修改配置,应同步评估 max_replication_slotsmax_wal_senders;文档要求后者不小于前者。还需要在 pg_hba.conf 中允许来自连接器所在网络的 replication 连接。把复制账号限制到实际来源网段,比为了“先跑通”而开放所有来源更合理。

第二,slot 的确认位置会影响 WAL 的回收。连接器只有在已处理的消息获得确认后才能推进已确认位置;如果下游持续阻塞,数据库就可能保留更多 WAL 段。它不是 Redpanda Connect 的“内存泄漏”,而是 CDC 链路没有完成确认的可预期信号。因此,数据库磁盘、slot 状态和下游 broker 的健康度应当一起监控。

用一份 YAML 把表范围、快照和输出边界固定下来

下面的配置只复制 public.orders。用户名、密码和 broker 地址均为示例,生产环境应通过受管密钥或运行时注入提供,不要把真实凭据提交到仓库。

input:
  postgres_cdc:
    dsn: "postgres://cdc_user:REPLACE_WITH_SECRET@postgres:5432/app?sslmode=require"
    schema: public
    tables:
      - orders
    slot_name: orders_cdc_slot
    stream_snapshot: true

output:
  redpanda:
    seed_brokers:
      - redpanda-0:9092
    topic: orders_cdc

其中 dsnschematablesslot_name 都是 postgres_cdc 的必要配置。tables 应只写需要同步的业务表:把整个 public schema 无差别复制,会扩大数据暴露面,也会让下游消费者承担不必要的兼容性成本。

stream_snapshot: true 表示先读取指定表的初始内容,再继续处理快照期间及其后的 WAL 变更;默认值为 false。这很适合首次构建搜索索引、分析仓或新消费者时避免只拿到“启动之后”的增量。但它也意味着下游必须能处理一段存量导入流,不能仅把每条消息都当作刚发生的事件。已经完成基线导入、只希望从启动时刻开始消费时,则应保持默认的流式模式,并把切换时间和消费者偏移策略记录下来。

初始快照还带来一个经常被忽略的排序边界:快照里的旧行与随后到来的增量并不天然等同于一条全局有序的业务事件流。消费者若要把数据写入搜索索引、缓存或分析表,应明确以什么字段判定新旧,例如业务更新时间、单调版本号或数据库提交位置;缺少这一规则时,一次迟到的重试就可能覆盖较新的投影。对于删除事件也应在契约中约定是物理删除、软删除标记还是 tombstone,而不是让每个消费者各自猜测。

不要把 replication slot 当作“创建后无需管理”的资源。为每条管道使用清晰、稳定且可追溯的 slot_name,避免多个测试实例抢用同一个 slot;在停用管道或迁移环境时,也要按 PostgreSQL 的变更流程清理不再使用的 slot。否则即使应用已经下线,未被推进的 slot 仍可能让 WAL 保留时间超出预期。将 slot 名、所复制的表、目标 topic 和负责团队登记在运行手册中,排障时能明显减少把一条遗留复制链误当成数据库故障的风险。

示例中使用 sslmode=require,避免把开发环境中常见的 sslmode=disable 原样带入生产。官方组件文档确实给出了禁用 SSL 的连接串示例,但明确限定为安全环境;生产应由数据库证书、网络隔离与账号权限共同承担保护,而不是靠一个连接参数“省事”。

输出使用 redpanda 组件,而不是当前已标记为废弃、将在下一个大版本移除的 kafka 输出组件。它向 Kafka broker 发送消息,并在把确认传回输入端之前等待 broker 确认。这条确认链正好把“数据库读取成功”和“下游已经接收”区分开:前者不足以宣称一条变更已经交付。

安装与启动:把配置文件当作可审查的部署单元

官方 README 提供的 Linux 安装方式会下载 rpk,随后可用它运行 Connect:

curl -LO https://github.com/redpanda-data/redpanda/releases/latest/download/rpk-linux-amd64.zip
unzip rpk-linux-amd64.zip -d ~/.local/bin/
rpk connect run ./orders-cdc.yaml

容器化运行时,可以把同一份 YAML 挂载到容器内,而不是把参数散落到编排文件的命令行中:

docker pull docker.redpanda.com/redpandadata/connect

docker run --rm \
  -v "$PWD/orders-cdc.yaml:/connect.yaml:ro" \
  docker.redpanda.com/redpandadata/connect run

这里的只读挂载并不能替代网络和身份权限控制,却能减少运行进程意外改写部署配置的机会。更重要的是,把 YAML 与数据库迁移、topic 创建和消费者版本一起纳入代码审查:表名变更、字段脱敏要求或主题切换都应是可追溯的变更,而非某位运维人员临时在终端里修改的状态。

不要只看进程:为 liveness 和 readiness 设置不同判断

数据管道最常见的误判是“容器没有退出,所以服务正常”。Redpanda Connect 提供两个适合编排平台使用的 HTTP 端点:/ping 是 liveness probe,始终返回 HTTP 200;/ready 是 readiness probe,只有输入和输出都建立连接时返回 200,否则返回 503。

这一区别值得落实为部署策略:重启判断可以调用 /ping,避免短暂的 broker 重连直接触发重启风暴;把流量接入、任务标记为可用或告警恢复判断交给 /ready。若 /ready 长时间为 503,应按链路方向排查:先看 PostgreSQL 的复制权限与 wal_level,再看 slot 是否可创建、DNS 和 TLS 是否可用,最后确认 broker 地址、主题权限与认证配置。不要只重启容器;重启无法修复被拒绝的复制连接,也无法让不存在的主题自动具备正确权限。

README 同时说明,该工具内置指标、追踪能力,并在连接 at-least-once 的输入和输出时默认提供 at-least-once 交付。这个承诺不等于端到端 exactly-once:消费者仍要能够处理重试带来的重复消息。实践上可用业务主键和变更版本做幂等写入,或在消费侧保存已处理事件标识;不要把“broker 已确认”误读成“所有下游副作用只发生一次”。

适用边界:让 CDC 负责搬运,不替代数据契约

这一方案适合需要把 PostgreSQL 增量数据稳定送往 Redpanda、索引、分析或异步服务的团队,尤其适合希望用一份声明式配置同时明确表范围、初始快照与探针行为的场景。它不自动解决字段演进、删除语义、个人数据脱敏或跨服务事务一致性。那些问题仍需要数据契约、主题版本、消费者幂等设计和访问控制共同处理。

上线前至少做一次故障演练:暂停 broker 可达性,观察 /ready、slot 和 WAL 磁盘;恢复后验证同一业务记录不会造成不可接受的重复副作用;再测试新增字段或表结构变更是否被消费者安全处理。CDC 的价值不只是把行变化“发出去”,而是让这条变化链在失败时仍然可观察、可解释、可恢复。

相关链接

发表评论

你的邮箱地址不会被公开,带 * 的为必填项。