Debezium MySQL连接器初始快照超时问题求助

从异常堆栈看，核心错误是MySQLTransactionRollbackException: Lock wait timeout exceeded，触发点在Debezium执行表锁（MySqlSnapshotChangeEventSource.tableLock）阶段。原因是目标表deviceuploadrecord每秒有大量插入/更新操作，Debezium默认初始快照会尝试获取表读锁，但被持续的写事务阻塞，触发MySQL的锁等待超时——这并非Debezium自身snapshot.timeout.ms参数控制的快照整体超时。

1. 改用无锁快照模式（推荐） #

Debezium支持基于InnoDB MVCC的无锁快照，无需锁表即可生成一致性快照，彻底避免锁冲突。需满足前置条件：

• MySQL开启binlog，格式为ROW
• 目标表为InnoDB引擎，且有主键/唯一非空键
• MySQL版本5.6+（支持一致性读）

修改连接器配置，添加以下参数：

"snapshot.locking.mode": "none",
"database.server.id": "1001"  // 设置唯一server id，避免与其他MySQL实例冲突

2. 调整MySQL锁等待超时参数 #

若无法使用无锁快照，可临时调大MySQL的锁等待超时阈值，给Debezium足够时间获取表锁：

SET GLOBAL innodb_lock_wait_timeout = 300;  // 设为300秒，可根据实际场景调整

注意：该参数影响全库锁等待行为，快照完成后建议改回默认值（50秒）。

3. 拆分同步任务 #

当前连接器同时同步两张表，可拆分为两个独立连接器分别同步deviceuploadrecord和deviceuploadmergerecord，缩小单任务锁表范围，降低冲突概率。

4. 排查并清理长事务 #

目标表上的未提交长事务会持续占用锁资源，导致Debezium无法获取表锁。可通过以下SQL排查：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

找到长事务后，协调业务方优化或终止该事务。

• snapshot.timeout.ms控制的是Debezium快照任务的整体超时，而非MySQL锁等待超时，因此调整该参数无法解决当前锁冲突问题。
• 连接器配置存在拼写错误：database.history.comsumer.ssl.truststore.password应改为database.history.consumer.ssl.truststore.password，否则数据库历史消费者的SSL配置会失效。

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