基于Debezium+Kafka的PostgreSQL至S3 CDC方案技术问询

1. 该架构是否适用于当前CDC场景？ #

完全适用。你的需求是每日同步约5GB数据、涉及90张表，且明确不需要高可用、扩展性、容错性及高速度，Debezium+单Broker Kafka的组合完全能覆盖：

• Debezium原生支持PostgreSQL的逻辑CDC，能精准捕获数据变更；
• 单节点Kafka作为中间缓存，足够承接每日5GB的吞吐量（平均每秒仅约1.2MB）；
• 配合Kafka Connect的S3 Sink Connector，可直接将数据落地到S3数据湖，数据流链路清晰简单。

2. Kafka部署选择Docker容器还是EC2手动安装更优？ #

优先选Docker容器部署：

• 部署效率高：一键拉取镜像、启动容器，无需手动处理JDK、依赖包等环境配置；
• 环境一致性：避免EC2手动安装时因系统版本、依赖差异导致的问题；
• 运维成本低：容器的启停、重启、迁移都更便捷，适合单节点这种轻量部署场景；
• 注意：部署时需将Kafka的数据目录挂载到EC2的EBS卷，防止容器销毁后数据丢失。

3. 该方案是否适合生产环境？ #

结合你的需求来看，是适合的：

• 你明确放弃了高可用、容错性等要求，成本优先，单Broker Kafka完全能满足低要求的生产同步需求；
• 但需明确风险：单节点故障会导致同步暂停，直到节点恢复，若你的业务能接受这种短暂中断，就可以投入生产；
• 补充：做好基础监控（比如监控Kafka磁盘使用率、Debezium同步状态），定期备份Kafka数据，就能降低生产风险。

4. Kafka故障时，Debezium是否会保留捕获的变更，待Kafka恢复后再传输？ #

会保留。Debezium基于Kafka Connect运行，当Kafka Broker不可达时：

• Kafka Connect会自动进入重试状态，未发送的变更记录会暂存在本地缓冲区（可通过producer.buffer.memory配置缓冲区大小）；
• 只要缓冲区未被撑满，待Kafka恢复后，Connect会自动将缓存的记录发送到Kafka，不会丢失数据；
• 你的场景每日数据量小，缓冲区默认配置即可覆盖短时间的Kafka故障。

5. Debezium故障恢复后，能否从故障前的断点继续读取变更？ #

可以实现断点续传：

• Debezium会将PostgreSQL WAL的读取位置（或快照后的偏移量）记录到Kafka的__consumer_offsets主题中（该主题默认持久化存储）；
• 当Debezium故障恢复后，会自动从上次记录的偏移位置继续读取PostgreSQL的变更数据，不会出现重复读取或数据遗漏的情况；
• 注意：需确保Kafka的__consumer_offsets主题数据未丢失（挂载EBS卷可避免）。

6. 针对该场景有哪些解决方案或建议？ #

• 选择合适的S3落地组件：直接使用Kafka Connect官方的S3 Sink Connector，无需额外开发，支持按时间、大小等规则将Kafka数据分区存储到S3，适配数据湖的后续处理；
• PostgreSQL前置配置：确保PostgreSQL的wal_level设置为logical，创建具备REPLICATION权限的数据库用户，为Debezium配置专属的复制槽；
• Docker部署优化：将Kafka、Debezium的配置文件和数据目录都挂载到EC2的EBS卷，避免容器重启后丢失配置和数据；
• 基础监控配置：用Prometheus采集Kafka、Debezium的指标（比如消息堆积量、同步延迟、连接状态），搭配Grafana做可视化监控，及时发现故障；
• 磁盘空间管理：定期清理Kafka的旧数据（通过log.retention.hours配置数据保留时长），或确保S3 Sink及时消费Kafka消息，避免Kafka磁盘占满；
• 备份策略：定期备份Kafka的数据目录和PostgreSQL的复制槽信息，防止极端情况下的数据丢失；
• 参数调优：调整Debezium的batch.size（批量提交大小）、poll.interval.ms（拉取间隔）等参数，适配每日5GB的同步量，减少不必要的请求开销。

内容的提问来源于stack exchange，提问作者user3281975