Confluent Cloud中MySqlCdcSource的ExtractField$Key转换失效问题

本地使用io.debezium.connector.mysql.MySqlConnector时，ExtractField转换正常，但Confluent Cloud的MySqlCdcSource连接器报字段找不到错误，实际topic中键是Struct(id=0000)，说明字段存在，以下是排查方向：

1. 键格式与转换器的兼容性问题 #

你配置了output.key.format = 'STRING'，同时用了key.converter = 'org.apache.kafka.connect.storage.StringConverter'且开启key.converter.schemas.enable = true。Confluent Cloud的托管连接器在处理STRING格式的键时，可能已经把原生的Struct序列化成了字符串（比如JSON格式的字符串），这时候ExtractField无法从字符串里提取结构化的id字段。

• 试试把output.key.format改成AVRO，和value格式保持一致，确保键在转换前是结构化的Schema对象；
• 或者调整key.converter.schemas.enable为false，同时验证键的序列化形式是否符合ExtractField的要求。

2. Predicate匹配逻辑是否正确 #

你的转换配置了transforms.extractKey.negate = true，意味着转换会应用在不匹配TopicDoestHaveIdField正则的topic上（也就是xxx、yyy表对应的topic）。

• 检查正则myconn\.sandbox\.(zzz|ooo)$是否准确，确认Confluent Cloud中topic的命名和本地完全一致（比如前缀是否正确）；
• 验证是否因为正则匹配错误，导致转换被错误地应用到了没有id字段的topic上。

3. 字段名大小写差异 #

部分托管连接器会自动转换数据库字段的大小写（比如把小写id转为大写ID），虽然本地显示是id，但Confluent Cloud的连接器输出的键schema里字段名可能是大写。

• 登录Confluent Cloud的Schema Registry，查看对应topic的键schema，确认字段名的实际大小写，再调整transforms.extractKey.field的值（比如改成ID）。

4. 托管连接器的特有配置差异 #

Confluent Cloud的MySqlCdcSource和原生Debezium连接器有默认配置差异，可能存在隐含的转换或序列化规则修改了键结构：

• 对比本地Debezium的配置和Confluent Cloud连接器的配置，检查database.server.name等核心参数是否一致；
• 查看Confluent Cloud连接器的文档，确认是否有默认开启的键转换逻辑，导致原始Struct结构被修改。

5. 开启Debug日志排查原始结构 #

临时将Confluent Cloud连接器的日志级别调整为Debug，查看ExtractField转换执行前的键结构具体内容，确认此时的键是否真的是包含id字段的Struct：

• 通过日志可以直观看到转换前的数据格式，排查是否有其他前置操作修改了键的结构。

内容的提问来源于stack exchange，提问作者José Vte. Calderón