Hotdry.
归档
systems-engineering

Postgres CDC生产经验：从ClickHouse一年实践看容错设计与监控指标

基于ClickHouse团队Postgres CDC一年生产部署经验，深入分析变更数据捕获流水线的容错设计、关键监控指标与回滚策略，提供可落地的工程参数与最佳实践。

在实时数据架构中，Postgres 变更数据捕获（CDC）已成为连接事务型数据库与分析型数据库的关键桥梁。ClickHouse 团队在过去一年中，通过其 ClickPipes 服务将 Postgres CDC 从私有预览推进到正式发布，积累了宝贵的生产经验。本文基于 ClickHouse 博客的年度回顾，结合其他生产实践，深入探讨 Postgres CDC 流水线的容错设计、监控指标与回滚策略。

重新连接的成本：一个被低估的生产陷阱

Postgres CDC 的核心机制是通过逻辑复制槽读取 WAL（Write-Ahead Log）变更。ClickHouse 团队在生产中发现了一个关键问题：重新连接复制连接的代价极高。

当 CDC 连接意外断开并重新建立时，Postgres 会从复制槽的restart_lsn（起始位置）开始读取，而不是从最后处理的 LSN（Log Sequence Number）继续。对于包含长时间运行、大规模或交错事务的工作负载，这意味着需要重新读取大量 WAL 数据，显著增加复制延迟。

ClickHouse 的解决方案是确保复制连接永不释放。通过基础设施层面的改进，他们避免了昂贵的重启周期。数据显示，在避免重新连接后，复制延迟在长时间运行事务期间的峰值显著降低。对于大型客户，这一改进将复制槽耗尽速率大幅降低，复制延迟始终保持在可控范围内。

可落地参数：

  • 连接超时设置：建议将wal_sender_timeout设置为至少 300 秒（5 分钟）
  • 心跳间隔：配置逻辑复制心跳，建议每 10 秒发送一次
  • 监控指标：重点关注pg_stat_replication视图中的write_lag、flush_lag和replay_lag

预检验证：在问题发生前拦截

Postgres CDC 涉及数百个边缘情况和各种陷阱。ClickHouse 团队投资构建了50 多项预检验证，在复制管道启动前发现问题。

这些验证包括：

  1. Postgres 复制配置验证：确保wal_level = logical，max_replication_slots和max_wal_senders配置正确
  2. 表结构检查：确认所有表都有主键或副本标识（replica identity）
  3. 权限验证：CDC 角色具有正确的REPLICATION权限
  4. 重复表检测：避免 ClickHouse 中出现重复表名
  5. 版本兼容性：检查 Postgres 版本支持逻辑复制
  6. 发布存在性：验证出版物（publication）已创建
  7. 从备用节点读取能力：支持从只读副本读取变更

实施要点：

  • 预检应在管道创建时执行，而不是在运行时失败
  • 错误消息应提供具体的修复步骤，而不仅仅是错误代码
  • 验证逻辑应开源共享，促进社区改进（如 PeerDB 的开源验证逻辑）

并行快照的优化：从 7 小时到 1 秒的飞跃

初始数据同步（快照）是 CDC 流水线的关键阶段。ClickHouse 最初使用并行快照技术，通过逻辑分区大表并并行处理这些分区。然而，存在一个架构缺陷：为了计算这些分区，系统运行了昂贵的COUNT和窗口函数查询来生成均匀大小的分区。

在多 TB 表上，这些查询可能需要数小时，并对源数据库造成实际压力。在某些情况下，生成分区的时间比实际数据传输还要长。

Cyera（ClickHouse 的大型开源用户）的贡献解决了这个问题。他们引入了基于 CTID 列的启发式块分区策略。CTID 是 Postgres 内部的行标识符，包含页面号和行号。新策略：

  • 不再依赖昂贵的分析查询
  • 使用简单的块大小启发式方法
  • 将分区生成时间从7 + 小时减少到不到 1 秒
  • 保持相同的并行度，零数据库压力

技术细节：

-- 传统方法：昂贵的COUNT查询
SELECT COUNT(*) FROM large_table;

-- 新方法：基于CTID的块分区
SELECT (ctid::text::point)[0]::bigint as page_number 
FROM large_table 
WHERE MOD((ctid::text::point)[0]::bigint, 100) = 0;

监控指标体系：从被动响应到主动预防

有效的监控是 CDC 流水线可靠性的基石。ClickHouse 团队的经验表明，监控应分为三个层次：

1. 基础设施层监控

  • 复制槽大小：pg_replication_slots视图中的pg_wal_lsn_diff函数计算槽大小
  • WAL 发送进程负载：pg_stat_replication中的state和sent_lsn
  • 磁盘空间使用：WAL 目录的空间使用率

2. 业务层监控

  • 提交延迟（Commit Lag）：源事务提交与目标应用变更之间的时间差
  • 吞吐量指标：每秒处理的行数、字节数
  • 错误率：解析错误、序列化错误、网络错误

3. 数据一致性监控

  • 行数对比：定期对比源表和目标表的行数
  • 校验和验证：关键列的 MD5 或 CRC32 校验和对比
  • 时间线一致性：确保变更按正确顺序应用

告警阈值建议：

  • 复制槽大小 > 10GB：警告级别
  • 提交延迟 > 30 秒：警告级别
  • 提交延迟 > 5 分钟：严重级别
  • 错误率 > 0.1%：立即调查

用户告警系统：降低 on-call 负载的关键

ClickHouse 团队最初为几乎每个用户操作和错误构建了内部告警。这种方法在前 100 个客户中效果显著，但随着规模扩大，告警量变得不可管理。

他们引入了用户面向的告警系统，通过 Slack 和电子邮件直接通知客户。错误被分为 10 多个类别，每个类别都提供：

  1. 问题描述：清晰说明发生了什么
  2. 修复步骤：具体的操作指南
  3. 升级路径：如何寻求进一步帮助

告警类别包括：

  • 意外的复制槽大小增长
  • 源数据库不可达
  • 下游物化视图不兼容
  • 网络连接问题
  • 权限变更

效果：on-call 负载降低了几个数量级，客户能够以自助方式解决问题。更重要的是，这些告警成为产品改进的反馈循环，团队定期审查告警模式以识别系统性问题。

容错与回滚策略

1. 磁盘溢出机制

当内存缓冲区满时，CDC 系统应将数据溢出到磁盘，而不是丢弃变更。ClickHouse 实现了：

  • 基于大小的溢出阈值（如内存使用超过 80% 时开始溢出）
  • 智能的溢出策略（优先溢出旧数据）
  • 恢复时的磁盘读取优化

2. 内存管理改进

通过更好的 Go 通道管理，实现了更高效的内存处理：

  • 有界通道防止生产者过快压倒消费者
  • 背压机制在目标系统过载时减慢读取速度
  • 内存池重用减少 GC 压力

3. 数据一致性视图

正在开发的数据一致性视图将提供：

  • 源与目标之间的数据差异可视化
  • 变更转换的完整追踪
  • 时间点恢复能力

4. 回滚检查点

实施定期检查点，支持：

  • 从特定 LSN 重新开始复制
  • 部分表重新同步
  • 模式变更回滚

数据建模挑战与解决方案

Postgres CDC 到 ClickHouse 面临的主要数据建模挑战是重复数据删除。ClickHouse 使用ReplacingMergeTree引擎，它将 UPDATE 作为追加处理，异步处理重复数据删除。

这意味着客户必须显式处理重复数据删除，通常通过：

  1. FINAL 子句：查询时使用SELECT ... FINAL
  2. 物化视图：创建去重后的物化视图
  3. 定期 OPTIMIZE：手动触发合并

ClickHouse 的改进方向：

  1. 轻量级 UPDATE 支持：利用 ClickHouse 3 中的低延迟 UPDATE 改进
  2. 唯一索引支持：在ReplacingMergeTree表上提供基于主键 / 唯一键的同步去重
  3. Postgres 兼容层：减少查询迁移工作量

复制槽管理最佳实践

基于 Gunnar Morling 的经验，以下是关键的最佳实践：

1. 使用 pgoutput 插件

  • 内置支持，无需额外安装
  • 二进制格式比 JSON 更高效
  • 支持细粒度的表、列、行过滤

2. 定义最大复制槽大小

-- 监控复制槽大小
SELECT slot_name, 
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) as slot_size
FROM pg_replication_slots;

3. 启用心跳

-- 配置逻辑复制心跳
ALTER SYSTEM SET wal_sender_timeout = '300s';

4. 使用表级发布

避免使用全数据库发布，而是为特定表创建发布：

CREATE PUBLICATION my_publication FOR TABLE table1, table2;

5. 监控与清理

  • 定期监控未使用的复制槽
  • 实施自动化清理策略
  • 设置复制槽大小告警

未来方向：Postgres 逻辑复制 V2

ClickHouse 团队正在评估对Postgres 逻辑复制 V2的支持。V2 允许在事务提交前从复制槽读取变更，这可以：

  • 显著减少 WAL 发送进程的负载
  • 大幅提高吞吐量
  • 改善复制槽耗尽
  • 更好地支持高级用例，特别是涉及大型或高度交错事务的场景

另一个重要改进是在初始快照和重新同步期间同时使用复制槽，允许两个过程同时进行，实现更高效的复制槽刷新。

总结：从 ClickHouse 经验中提取的关键教训

  1. 可靠性需要迭代：CDC 看似简单（"只是读取 WAL"），但实际工作负载暴露了长时间运行事务、复制槽背压、模式变更等边缘情况。

  2. 监控应分层级：基础设施监控、业务监控和数据一致性监控缺一不可。

  3. 用户教育是关键：通过用户面向的告警和文档，减少支持负载并提高客户满意度。

  4. 性能优化需要创造性思维：从昂贵的分析查询到基于 CTID 的启发式方法，展示了工程创新的价值。

  5. 容错设计应从第一天开始：心跳机制、故障转移槽、磁盘溢出等应在架构设计阶段考虑。

最终建议：对于计划实施 Postgres CDC 的团队，建议从 ClickHouse 和 PeerDB 的开源实现开始，借鉴他们的预检验证、监控指标和容错机制。记住，好的基础设施应该是 "无聊的"—— 可靠、不可见、快速。

参考资料：

  1. ClickHouse 博客："Postgres CDC in ClickHouse, A year in review" (2025-12-03)
  2. Gunnar Morling："Mastering Postgres Replication Slots: Preventing WAL Bloat and Other Production Issues" (2025-07-08)
查看归档