PeerDB项目中CDC同步中间表的存储优化实践

背景介绍

在PostgreSQL数据库同步场景中，CDC(变更数据捕获)技术被广泛应用。PeerDB作为一款开源的PostgreSQL数据同步工具，在实现PostgreSQL到PostgreSQL的CDC同步过程中，会创建名为_peerdb_internal._peerdb_raw的中间表用于暂存变更数据。随着业务数据量的增长，这类中间表往往会面临存储膨胀的问题。

问题现象

在实际使用中，用户发现_peerdb_raw表会持续增长，达到数十GB的规模。这不仅占用大量存储空间，还可能影响数据库整体性能。类似的情况也出现在使用MinIO作为中间存储时，存储桶空间会不断膨胀。

技术原理

PeerDB的CDC同步流程包含两个关键阶段：

1. 原始变更捕获阶段：从源数据库捕获的变更数据首先写入_peerdb_raw中间表
2. 数据规范化阶段：从中间表读取数据并应用到目标表的最终形态

_peerdb_raw表记录了所有表的变更数据，每条记录包含_peerdb_batch_id字段标识所属批次。系统通过metadata_last_sync_state表跟踪已处理的批次ID。

存储优化方案

PostgreSQL中间表清理

对于PostgreSQL中的_peerdb_raw表，可采用以下清理策略：

1. 安全清理：首先查询已处理的最新批次ID

SELECT normalize_batch_id 
FROM metadata_last_sync_state 
WHERE job_name = '同步任务名称';

2. 执行清理：保留最近几个批次作为缓冲，删除更早的数据

DELETE FROM _peerdb_internal._peerdb_raw_表名 
WHERE _peerdb_batch_id < 最新批次ID-缓冲值;

3. 自动化方案：可创建定期执行的清理脚本或触发器

MinIO存储优化

对于MinIO中的中间数据，建议配置生命周期管理规则自动过期旧数据：

1. 设置基于时间的过期策略，如保留最近7天的数据
2. 根据业务同步延迟情况调整保留时长
3. 确保保留窗口覆盖可能的同步延迟峰值

ClickHouse中间表处理

ClickHouse作为目标库时也会产生类似的中间表。清理策略与PostgreSQL类似，但需注意：

1. ClickHouse的DELETE操作代价较高，建议使用TTL功能
2. 可配置表级别的TTL策略自动清理旧数据
3. 定期执行OPTIMIZE TABLE命令回收空间

最佳实践建议

1. 监控预警：建立中间表空间使用监控，设置合理阈值
2. 定期维护：将清理操作纳入常规数据库维护计划
3. 容量规划：为中间表预留足够的存储空间
4. 缓冲设计：清理时保留适当缓冲批次，防止同步中断
5. 测试验证：任何清理操作前应在测试环境验证影响

总结

CDC同步过程中的中间表管理是保证系统稳定运行的重要环节。通过理解PeerDB的同步机制，实施合理的清理策略，可以有效控制存储增长，同时确保数据同步的可靠性。建议用户根据自身业务特点和同步延迟情况，定制适合的中间数据保留策略。