Apache Kafka Connect从MySQL到PostgreSQL的同步架构设计咨询

连接器选型说明 #

不能仅依赖Debezium连接器，需要搭配两类组件完成同步：

• 源端：Debezium MySQL Connector（负责捕获MySQL的全量快照+增量CDC变更，是核心组件）
• 目标端：推荐使用Confluent JDBC Sink Connector（适配PostgreSQL批量写入、字段映射等需求，灵活性更强；也可选用Debezium PostgreSQL Connector，但JDBC Sink更适合通用场景）

源连接器数量规划 #

针对300+张表、100GB数据量，建议拆分配置2-3个Debezium MySQL源连接器：

• 按业务域或表的读写热度拆分，比如核心交易表单独一个连接器，普通业务表一个，日志/归档类表一个
• 单连接器负责的表数控制在100-150张以内，避免快照阶段和增量捕获阶段出现性能瓶颈，同时便于故障隔离和单独监控

主题数量规划 #

每张MySQL表对应1个独立的Kafka主题，总计300+个主题。
采用Debezium默认主题命名规则{server-name}.{database-name}.{table-name}，便于快速识别表来源和定位问题。

主题分区数规划 #

分区数根据表的业务吞吐量设置：

• 核心交易表（高QPS、大流量）：4-8个分区，匹配Sink端并行处理能力，避免同步延迟
• 普通业务表：2-4个分区，平衡同步效率和集群资源占用
• 日志/归档表（低流量、更新频率低）：1个分区即可
• 整体分区总数建议控制在1000以内，避免给Kafka集群带来过高负载

Sink连接器数量规划 #

与源端连接器的拆分逻辑对应，配置2-3个Sink连接器：

• 每个Sink连接器通过table.whitelist过滤对应业务域的表，实现并行同步，提升整体效率
• 若存在特殊需求的表（比如字段重命名、自定义转换逻辑），可单独配置1个Sink连接器处理这类表，避免影响其他表的同步

关键配置补充 #

• 源端Debezium：开启initial快照模式（全量同步后自动切换增量CDC），设置snapshot.locking.mode=minimal减少对MySQL的锁影响，调整snapshot.chunk.size=10000优化快照导出速度
• Sink端JDBC：开启auto.create/auto.evolve（按需启用，避免误删字段），设置batch.size=1000优化批量写入性能，配置max.retries=3处理临时写入失败
• 转换处理：使用内置转换ExtractNewRecordState去掉Debezium的CDC envelope结构，直接将业务数据写入PostgreSQL，简化Sink端处理逻辑

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