Debezium CDC同步事件丢失排查求助：MySQL从库数据未写入Kafka
2026-8-2
问题排查与分析
一、Debezium跳过Binlog位置的可能场景
- Binlog清理策略冲突：若MySQL从节点的binlog清理（如
expire_logs_days配置）速度快于Debezium的读取速度，当连接器重启或出现延迟时，可能错过已被清理的binlog片段。即便主从同步正常，也需确认从节点binlog是否完整保留了Debezium所需时间段的日志。 - 连接器偏移量异常：检查连接器的
snapshot.mode和偏移量存储配置。如果使用schema_only或initial快照后偏移量记录损坏，或offset.storage对应的存储（如Kafka偏移量主题）出现异常，连接器重启后可能从错误的binlog位置开始读取，跳过部分事件。 - 大事务/DDL阻塞导致的断点丢失：当MySQL存在超大事务时，Debezium解析耗时较长，若此时连接器重启，可能导致事务未完全处理，后续跳过该事务的部分事件。此外，某些DDL操作（如ALTER TABLE）触发Debezium重新快照时，若快照过程中遗漏增量数据，也会引发记录丢失。
- Binlog事件解析失败：Debezium依赖MySQL的
binlog_position和gtid定位读取位置，若从节点GTID集合异常（如主从切换后GTID未同步），或Debezium对特殊binlog事件（如自定义存储过程调用）解析失败，可能会跳过后续事件。
二、MySQL Binlog未记录事件的可能情况
- Binlog格式与隔离级别不匹配：若MySQL使用
READ UNCOMMITTED隔离级别并搭配STATEMENT格式binlog，可能存在未被记录的隐式修改；使用MIXED格式时，含非确定性函数的语句转为STATEMENT模式后，Debezium可能无法正确捕获。需确认从节点binlog_format是否为Debezium推荐的ROW格式。 - 特殊表操作不写入Binlog：MySQL临时表、内存表的变更不会写入binlog，Debezium自然无法捕获这类表的操作，需检查丢失记录是否来自这类特殊表。
- 操作类型被过滤：Debezium默认捕获INSERT/UPDATE/DELETE，但如果连接器配置
include.query=false，且部分操作通过LOAD DATA INFILE等特殊方式执行，可能无法生成CDC事件。同时需核对table.include.list或column.include.list是否误过滤了相关表或字段。 - Binlog异步刷写丢失：若从节点设置
sync_binlog=0（异步刷写binlog），当从节点宕机重启时，可能存在已同步到从库但未写入binlog的数据，导致Debezium无法读取。
三、针对性排查步骤
- 检查Debezium连接器日志：搜索日志中
binlog position、gtid相关内容，确认是否存在跳过位置的警告或错误（如Skipping binlog event due to missing table metadata）。 - 直接解析从节点Binlog：使用
mysqlbinlog工具解析从节点binlog，定位丢失记录的时间范围，确认对应操作是否存在于binlog中：mysqlbinlog --start-datetime="2024-05-01 10:00:00" --stop-datetime="2024-05-01 11:00:00" mysql-bin.000001 - 核对连接器偏移量：查看Debezium存储的偏移量（通常在
__consumer_offsets主题或指定存储中），对比从节点当前的binlog位置，确认是否存在偏移量跳跃。 - 小批量数据链路测试：手动插入/更新/删除一批测试数据，跟踪从MySQL从节点binlog到Debezium捕获再到Kafka的全链路，验证事件是否能正常流转，缩小问题范围。
内容的提问来源于stack exchange，提问作者ArefehTam
相关产品推荐
相关产品推荐
