Debezium启动失败主因是缺失MySQL JDBC驱动、MySQL未启用ROW格式Binlog与GTID、或多个Connector共用相同database.server.id；需确保插件目录含debezium-connector-mysql和mysql-connector-j-8.x，MySQL配置binlog_format=ROW、gtid_mode=ON并重启，且各Connector的server.id唯一。
Debezium启动失败：找不到MySQL连接器或报错ClassNotFoundException
Debezium本身不自带数据库驱动，必须手动把对应JDBC驱动放进Kafka Connect插件目录。常见错误是只下载了debezium-connector-mysql的jar包，却忘了放mysql-connector-j（8.x版本）。
- 确认
connectors/目录下同时存在：debezium-connector-mysql-2.5.0.Final.jar和mysql-connector-j-8.3.0.jar - MySQL 8+ 必须用
mysql-connector-j（不是旧版mysql-connector-java），否则会抛java.lang.NoClassDefFoundError: com/mysql/cj/jdbc/Driver - Kafka Connect启动后，用
curl http://localhost:8083/connector-plugins检查返回列表里是否含io.debezium.connector.mysql.MySqlConnector
MySQL Binlog配置不生效：Kafka中无变更事件
Debezium依赖MySQL的ROW格式Binlog + 启用GTID，缺一不可。即使my.cnf写了配置，若未重启MySQL或用户权限不足，依然无法捕获数据。
- MySQL需开启：
binlog_format = ROW、gtid_mode = ON、enforce_gtid_consistency = ON，且重启生效 - 创建的Debezium用户必须有：
REPLICATION SLAVE、REPLICATION CLIENT、对目标库的SELECT - 验证是否就绪：登录MySQL执行
SHOW MASTER STATUS;，非空结果 +File字段有值才算Binlog真正启用
Connector配置里database.server.id重复导致offset冲突
同一个MySQL集群下，多个Debezium Connector不能共用相同database.server.id。Kafka Connect会把它当作同一“逻辑复制客户端”，导致位点覆盖、丢事件甚至连接被MySQL主动踢掉。
-
database.server.id必须是唯一整数（如5400、5401），不能写成范围（如5400-5401）——那是旧版写法，新版已弃用 - 如果复用同一MySQL实例做多库监听，每个Connector配不同
server.id，哪怕只监听一个库也要独立 - 修改
server.id后必须删除对应Connector并重建，仅更新配置不生效
Java应用消费CDC消息时反序列化失败
Debezium输出的消息value是Avro或JSON Schema格式，默认带嵌套结构（before/after/source等字段）。直接用StringDeserializer拿到的是JSON字符串，但字段名、null值、时间戳格式都和原始表不一致。
立即学习“Java免费学习笔记（深入）”；
- 推荐用
JsonConverter配schemas.enable=false简化结构，避免Schema Registry依赖 - 关键字段提取别硬写
jsonObject.getJSONObject("after").getString("name")——after可能为null（DELETE事件），应先判空 - 时间类型字段（如
timestamp）在JSON里是长整型毫秒值，不是ISO字符串；若用Jackson反序列化，需注册JavaTimeModule并设DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE为false
server.id得像身份证号一样唯一。其余问题，基本都是这三处没踩实。 
