Debezium MySQL CDC连接器异常终止及快照恢复失败问题咨询

错误原因解析 #

第一个错误：Encountered change event for table i9.workshop whose schema isn't known to this connector #

这个错误的核心是连接器无法找到对应表的元数据，常见诱因如下：

• DB History Topic 元数据损坏：虽然你配置了无限保留，但Kafka Topic可能出现数据损坏、部分记录丢失，或者连接器之前运行时没有正确将表结构元数据写入该Topic，导致重启后无法识别表结构。
• Debezium 0.9.2版本的固有缺陷：这个2019年的旧版本存在元数据处理、GTID过滤相关的bug，比如启用gtid.source.filter.dml.events=true时，可能会跳过必要的表元数据同步事件，导致连接器无法加载表结构。
• 元数据加载逻辑异常：即使表没有Schema变更，连接器重启后优先从DB History Topic加载元数据，如果Topic中没有该表的元数据记录，就会触发这个错误。

第二个错误：java.lang.ArrayIndexOutOfBoundsException: 35 #

切换到snapshot.mode=schema_only后出现的数组越界错误，根源在于：
该模式下连接器会尝试结合DB History Topic中的旧元数据和当前数据库的表结构生成记录，但由于History Topic中的元数据已经损坏，或者和当前表结构不匹配，触发了Debezium 0.9.2版本中TableSchemaBuilder类的已知bug——这个问题在后续版本中已经被修复。

解决方法 #

临时恢复步骤（快速让连接器恢复运行） #

1. 停止当前的Mysql-cdc-engagex-test连接器实例。
2. 删除损坏的DB History Topic：

   kafka-topics.sh --delete --topic testing_engagex_dbhistory_test --bootstrap-servers <your-kafka-bootstrap-servers>
   

3. 修改连接器配置，添加或设置snapshot.mode=initial，让连接器重新执行全量快照，生成全新的元数据到新的History Topic。
4. 重启连接器，等待全量快照完成，之后连接器即可正常处理binlog事件。

永久解决措施（避免问题再次发生） #

• 升级Debezium版本：这是最关键的一步，0.9.2版本过于老旧，后续的1.0+版本（推荐使用最新稳定版，比如2.x系列）修复了大量元数据处理、GTID相关的bug，包括你遇到的数组越界问题。
• 优化DB History Topic配置：
  • 将database.history.store.only.monitored.tables.ddl从false改为true，让History Topic只存储你监控的表的DDL，减少无效数据积累。
  • 为History Topic添加cleanup.policy=compact配置，让Kafka自动清理旧的、不再需要的元数据记录，降低Topic损坏概率。
• 调整GTID相关配置：确保MySQL的GTID模式正常启用，同时可以考虑关闭gtid.source.filter.dml.events=true（如果业务不需要该过滤逻辑），避免跳过必要的元数据事件。
• 定期备份DB History Topic：使用Kafka的备份工具（如kafka-backup）定期备份History Topic，避免出现损坏后无法恢复的情况。

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