JDBC Source Connector配置tasks.max=5仅创建1个任务的排查求助

可能的原因 #

1. 增量列数据分布无法支撑多任务拆分 #

JDBC Source Connector在timestamp+incrementing模式下，会查询增量列（此处为ID）的最小值和最大值，将数据范围平均拆分给每个任务。如果ID列的数值范围过小（比如表中数据量少、ID跨度不大），或者数值分布极度集中，连接器会判定无需拆分多任务，仅启动1个任务处理所有数据。

2. Oracle用户权限不足 #

连接器需要读取Oracle系统视图（如ALL_TAB_STATISTICS、USER_TAB_COLUMNS）获取表的统计信息，以此计算任务拆分范围。如果配置的USER_ID没有这些视图的查询权限，连接器无法拿到有效数据，只能 fallback 到单任务模式。

3. 连接器版本兼容性bug #

Debezium 1.7搭配Kafka 2.8.1时，Confluent JDBC Source Connector在Oracle的timestamp+incrementing模式下存在任务拆分逻辑的已知问题，部分场景下无法正确识别tasks.max配置。

4. 时间戳列数据分布过于集中 #

如果LAST_UPDATED_TS列的大部分数据时间戳完全一致，连接器无法通过时间维度拆分任务，只能依赖ID列的范围拆分；若此时ID列也不满足拆分条件，就会仅生成1个任务。

解决办法 #

针对增量列分布问题 #

• 手动指定增量列的拆分范围，添加以下配置参数：

  "split.min": "1",
  "split.max": "1000000"
  

  （根据实际ID列的最大/最小值调整数值，确保范围足够拆分出5个任务）
• 若表中数据量确实极少，单任务是合理行为；若数据量大但ID分布异常，需检查ID列是否严格唯一递增（incrementing.column.name要求列值唯一且持续递增）。

针对权限问题 #

• 给数据库用户授予必要的查询权限：

  GRANT SELECT ON ALL_TAB_STATISTICS TO USER_ID;
  GRANT SELECT ON USER_TAB_COLUMNS TO USER_ID;
  

• 刷新表的统计信息，确保连接器能获取最新数据分布：

  ANALYZE TABLE TABLE001 COMPUTE STATISTICS;
  

针对版本兼容性问题 #

• 升级Debezium/Connect镜像到1.8及以上版本，后续版本修复了多个JDBC任务拆分的bug；若无法升级，可尝试将tasks.max的配置值改为数字类型（去掉引号，即"tasks.max": 5）。

针对时间戳列分布问题 #

• 检查LAST_UPDATED_TS列的赋值逻辑，确保数据更新时该列能正确生成不同的时间戳（比如使用SYSTIMESTAMP而非固定值），让连接器可以结合时间维度拆分任务。

辅助排查步骤 #

• 查看Connect集群的日志，搜索任务初始化相关的日志，是否存在权限报错、列值查询失败等信息，直接定位具体问题。

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