Debezium MySQL全库变更同步失效问题求助

一、是否推荐配置全库同步连接器？ #

不推荐直接使用全库同步配置，核心原因有三点：

• 性能冗余：全库同步会包含MySQL系统库（如mysql、information_schema）的无关变更，占用Kafka存储、连接器CPU和网络资源，增加不必要的同步负载。
• 数据安全隐患：容易同步到敏感系统数据（如用户权限表），可能违反数据合规要求。
• 运维不可控：后续新增库表会自动纳入同步范围，易引发意外的数据流变更，增加问题排查难度。
  建议通过database.include.list或table.include.list精准指定需要同步的库表，保持同步范围可控。

二、全库连接器失效的原因分析 #

结合你的配置和现象，主要排查以下几个方向：

1. MySQL用户权限不足
   Debezium的同步用户需要具备读取所有数据库的权限。如果debezium用户仅拥有dbtest库的访问权限，全库同步时无法读取其他库的元数据和变更，自然没有数据输出。
   验证命令：

SHOW GRANTS FOR 'debezium'@'%';

需确保用户拥有SELECT ON *.*的权限。

2. 无变更触发或快照无数据
   全库连接器启动时默认执行快照同步，如果所有库表都没有数据，且启动后未触发任何DML（增删改）或DDL（建表等）操作，Watcher容器就看不到变更数据。可尝试在任意库表插入一条数据，再观察日志输出。

3. Schema历史Topic冲突
   你的全库连接器使用的schema.history.internal.kafka.topic为schema-changes，而测试连接器使用的是schema-changes.dbtest。若测试连接器的历史数据干扰了全库连接器的Schema初始化，会导致同步异常。建议给全库连接器配置独立的Schema历史Topic，比如schema-changes.all。

4. MySQL Binlog配置不符合要求
   Debezium要求MySQL的Binlog格式为ROW，且binlog_row_image为FULL，否则无法捕获行级变更。验证命令：

SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';

补充验证步骤 #

• 检查连接器状态：通过Kafka Connect的REST API执行GET /connectors/general-connector/status，确认任务是否处于RUNNING状态。
• 查看Kafka Connect日志：排查是否有权限错误、初始化异常等日志信息。

内容的提问来源于stack exchange，提问作者Alessandra Nuñez