SymmetricDS无规律跳过批次导致主从数据库数据不匹配/缺失问题咨询

核心问题根因定位方向 #

• 批次归属节点ID不匹配
  从日志可以明显看到服务端AcknowledgeService报错找不到的是前缀为001-的批次，而客户端IncomingBatchService标记为已加载跳过的是前缀为000-的同ID批次，说明节点组ID或者外部ID配置存在映射错误，客户端拉取到批次后记录的归属节点ID与服务端生成批次时的节点ID不一致，导致服务端收到ACK请求时无法匹配到对应批次记录，客户端却认为批次已经加载完成后续直接跳过。
• 批次保留时长配置过小
  SymmetricDS默认会启动后台定时任务清理已经完成同步的批次记录，如果你手动修改过outgoing.batches.max.retention.minutes或者incoming.batches.max.retention.minutes参数，且数值设置过小，会导致批次还没完成完整的ACK确认流程就被清理任务删除，就会出现服务端找不到批次的报错。
• 3.10.13版本已知并发BUG
  你使用的3.10.13版本存在AcknowledgeService并发处理漏洞：当多个拉取请求同时处理同一客户端节点的批次时，部分批次的状态会被提前标记为已完成并进入清理队列，后续正常的ACK请求到达时就无法找到对应的批次记录。
• 跨数据库事务提交不一致
  源库PostgreSQL和目标库SQL Server的事务隔离级别配置存在差异时，可能出现源库事务已经提交、SymmetricDS生成批次但还没写入 outgoing_batch 表，就被拉取请求发送到客户端，客户端加载完成后回发ACK，服务端还没生成批次记录就会报错找不到，后续批次生成后又会被客户端判定为已加载直接跳过，导致数据丢失。

验证修复方案 #

• 先执行SQL查询对应批次的状态：
  服务端执行：select * from sym_outgoing_batch where batch_id in (315947,315950,315954,315957,315960);
  客户端执行：select * from sym_incoming_batch where batch_id in (315947,315950,315954,315957,315960);
  对比查询结果的node_id字段，确认是否存在前缀不匹配的问题。
• 检查节点配置：确认corp-000节点的组ID是否为001，store-001节点的组ID是否为000，路由规则中的节点ID映射、通道配置是否正确。
• 版本BUG修复可以升级到3.10系列的最新维护版3.10.18，该版本已经修复了并发ACK处理的相关问题。

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