Debezium报db history topic缺失错误的解决方案及配置疑问

你之前删除历史主题后重启仍报错，核心原因是没有清理Kafka Connect保存的旧消费偏移量：连接器启动时会按照之前持久化的offset拉取历史主题内容，主题被删除后旧offset指向的位置不存在，自然会持续抛出缺失错误。按以下步骤操作即可修复：

• 先停掉所有连接该数据库的Debezium连接器实例，不要留运行中的进程。
• 删除已损坏/丢失的database history kafka主题，等待所有Broker节点上的主题删除操作完全生效后再进行下一步。
• 清理连接器的持久化状态：如果是分布式模式部署Kafka Connect，需要进入Connect内部依赖的三个存储主题（默认是connect-configs、connect-offsets、connect-statuses），删除所有和这些连接器关联的记录；如果是单机模式部署，直接删除本地存储偏移量的对应文件即可。
• 临时将第一个启动的连接器的snapshot.mode配置改为schema_only_recovery，单实例启动，等它完成全量schema历史重建、将所有库表元数据写入db history topic，且能正常消费binlog无报错后，再把这个连接器的snapshot.mode改回schema_only，重启生效。
• 第一个连接器稳定运行后，再逐个启动同库的其他连接器，不要批量同时启动。

你之前切换schema_only_recovery后启动第二个连接器报"schema isn't known to this connector"错误，就是因为第一个连接器还没完成schema历史重建，第二个连接器启动时读到的是不完整的历史记录，找不到自己监听表对应的元数据导致的。

同database.server.name配置下的多个连接器完全支持共享同一个db history topic，这也是官方推荐的用法，不存在多连接器不能共享的限制，你之前遇到的冲突都是操作顺序和配置使用错误导致的。共享时需要遵守几个规则：

• 硬约束：只有database.server.name配置完全一致的连接器才能共用同一个db history topic，不同逻辑库的连接器混用同一个历史主题，会直接导致元数据错乱。
• 重建场景约束：当历史主题损坏/丢失需要用schema_only_recovery模式重建时，只能同时启动一个连接器执行恢复操作，等它把完整的schema历史写入主题、稳定运行后，再启动其他连接器。schema_only_recovery模式会覆写历史主题内容，多个实例同时启动写主题会直接把历史数据写坏，触发schema找不到的错误。
• 稳定运行阶段无冲突：所有连接器在正常schema_only模式下运行时，只会读取历史主题里的schema元数据，不会修改已有内容，多实例共享不会产生任何冲突，还能避免重复存储schema历史浪费存储空间。

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