Kafka复制异常：SQL Server与PostgreSQL表记录数不匹配求助

一、核对连接器核心配置 #

• 检查SQL Server源连接器的同步模式：如果用incrementing或timestamp模式，确认指定的递增/时间戳字段无重复、无NULL值——这类字段异常会直接导致漏读记录。比如incrementing.column.name对应的字段有重复值时，连接器会跳过后续重复项。
• 检查PostgreSQL Sink连接器的表结构适配配置：auto.create/auto.evolve是否开启？SQL Server与PostgreSQL的字段类型是否匹配（比如SQL Server的uniqueidentifier要对应PostgreSQL的uuid），类型不兼容会导致插入失败丢数据。
• 确认批量处理参数：batch.size过大可能导致插入超时，max.retries不足会让失败的批量数据直接丢弃，这两个参数需要根据实际数据量调整。

二、排查连接器运行日志 #

• 在Conduktor中直接查看源、Sink连接器的日志，搜索error、failed、skip关键词：
  • 源端日志：排查是否有权限不足、表锁导致的读取失败，或是连接器跳过了某些记录。
  • Sink端日志：重点看是否有违反唯一约束、字段长度超限、空值约束的报错——这些都会导致数据无法写入PostgreSQL。
• 对比Kafka主题消息数：统计源表总记录数和对应Kafka主题的消息总量，如果主题消息数和源表一致，问题出在Sink端；反之则是源端同步不完整。

三、分段校验数据一致性 #

• 用分段统计定位缺失数据的范围，避免全表统计的盲目性：

  -- SQL Server分段统计示例（按ID每1000条分段）
  SELECT FLOOR(id/1000) AS segment, COUNT(*) AS cnt FROM your_target_table GROUP BY FLOOR(id/1000);
  -- PostgreSQL对应分段统计
  SELECT FLOOR(id/1000) AS segment, COUNT(*) AS cnt FROM your_target_table GROUP BY FLOOR(id/1000);
  

• 检查DELETE操作是否同步：如果源连接器未开启delete.enabled（Debezium连接器参数），SQL Server的DELETE操作不会同步到PostgreSQL，会直接导致两边记录数差异。

四、检查连接器偏移量状态 #

• 在Conduktor中查看源连接器的偏移量（offset），确认是否已读取到SQL Server表的最新数据。如果偏移量停滞在某个时间点，说明源连接器卡住，未继续同步新数据。
• 查看Sink连接器的偏移量，确认是否已消费完Kafka主题的所有消息。如果Sink偏移量落后于主题最新偏移量，说明Sink端消费阻塞或速度过慢。

五、特殊场景排查 #

• 检查SQL Server表是否有隐式数据变更：比如IDENTITY字段自动生成值、触发器或视图导致的数据修改，部分连接器可能无法捕获这类隐式变更。
• 检查PostgreSQL表的触发器/规则：是否存在插入后自动删除、合并数据的逻辑，这类逻辑会导致写入的数据被修改，造成记录数不符。
• 排除并发写入干扰：同步过程中SQL Server有新数据写入时，两端统计的时间点不一致会导致临时差异。可以暂停业务写入后再重新统计对比。

六、极端情况的解决手段 #

• 全量重同步：
  1. 暂停并删除当前的源、Sink连接器。
  2. 备份PostgreSQL目标表后清空数据。
  3. 重置对应Kafka主题的偏移量，或直接删除主题后重建。
  4. 重新配置源连接器，使用initial（全量同步）模式启动，确保从头读取SQL Server表的所有数据。
• 更换连接器类型：如果用Conduktor自带连接器问题持续，尝试使用Debezium官方的SQL Server和PostgreSQL连接器，兼容性可能更好。

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