MySQL CDC 同步延迟排查：从 binlog 位点到反压的根因定位

遇到 MySQL CDC 同步延迟，先别急着重启作业。绝大多数“位点不动、消费变慢、重启后从旧位点重放”的故障，都能归入四类根因：连接被切断（keep-alive / timeout）、binlog_format 非 ROW、GTID 或位点失效、下游反压导致停读。先用监控曲线和作业日志确认现象属于哪一类，再对症处理，比盲目调参有效得多。

一、先给症状分型

三种可观察症状对应不同的排查方向：

• 作业进程存活但消费停滞：日志停更、source 不再输出记录、监控曲线呈水平线。方向：连接被切断，或 GTID / 位点失效。
• 消费在跑但 lag 持续增长：消费速率低于变更产生速率。方向：下游反压、资源不足或热点分区。
• 作业重启后从很旧的位点重放：方向：offset 未落盘、位点失效触发重新快照，或续传配置错误。

判定第一步是分清“读不到 binlog”和“读到了但写不出去”。两者在监控上都表现为 lag 上涨，但处理路径完全不同。

二、四类根因与判定方法

根因 1：连接被切断（keep-alive / timeout）

MySQL 服务端的 wait_timeout、interactive_timeout 控制空闲连接存活时长，net_write_timeout、net_read_timeout 控制写读超时。CDC 作业在低峰期长时间收不到 binlog 事件时，连接可能被服务端或中间的负载均衡 / 代理判定为空闲并切断。典型表现：作业日志出现 Communications link failure、connection reset 或重连堆栈；重连后从上次已提交位点继续，期间产生的延迟被放大。

判定方法：查作业日志是否出现连接类异常；用 SHOW PROCESSLIST 查看该连接的状态与持续时长；确认链路上是否有 LB 或代理设置了独立的空闲超时。

处理要点：

• 适当调高 wait_timeout（全局或账号级），可写入 my.cnf 的 [mysqld] 段，或用 SET GLOBAL 对新连接动态生效。
• 在 CDC 链路中启用心跳机制，避免连接被判为空闲。Debezium 的 heartbeat.interval.ms 配置正是为此存在（默认 0 表示关闭），可设为一个较小的毫秒值定期产生心跳事件。
• 确认中间层代理的空闲超时大于 MySQL 侧的超时设置，否则只调 MySQL 参数无效。

根因 2：binlog_format 非 ROW

MySQL 8.0 之前的实例常见 binlog_format 为 STATEMENT 或 MIXED。以 Debezium MySQL 连接器文档 为依据，基于 binlog 的 CDC 连接器以 ROW 格式的行变更事件为前提；binlog 中只有语句而没有行镜像时，连接器无法解析出变更数据。注意 binlog_format 对已开启的事务不生效，切换后要确认新事务已写入 ROW 格式事件。

处理顺序：

1. 检查：SHOW VARIABLES LIKE 'binlog_format';，同时确认 binlog_row_image 为 full（否则 UPDATE / DELETE 缺少完整行镜像，下游按主键匹配会失败）。
2. 临时会话级切换可用 SET GLOBAL binlog_format='ROW';，但推荐写入配置文件，避免重启后回落。
3. 切换后重新核对作业读取位点处的事件格式，确认已能解析出 row 事件。

根因 3：GTID 失效与位点丢失

GTID 模式下，连接器记录的位点是 GTID 集合。若源库 binlog 被清理（受 expire_logs_days 或 MySQL 8.0.21+ 的 binlog_expire_logs_seconds 控制），连接器要求的事务在服务器上已不存在，恢复会失败或触发重新快照。典型报错包含 “binlog contains GTIDs that are not present” 一类表述，可参考 Confluent Cloud MySQL CDC（Debezium）连接器文档 对位点失效场景的说明。

判定方法：

• SHOW BINARY LOGS 查看最老 binlog 文件与时间。
• MySQL 8.4 起用 SHOW BINARY LOG STATUS，旧版本用 SHOW MASTER STATUS，查看当前 GTID 执行集。
• 对比作业最后提交位点对应的 GTID 是否仍在保留范围内。

处理要点：

• 将 binlog 保留时长设置为大于最长允许的作业停机时间，并留出冗余。
• 若历史 binlog 已被清理，只能重建：先做 schema-only 快照，再以增量方式续传，恢复后对下游做幂等去重或对账。

根因 4：下游反压导致停读

source 不是“读得慢”，而是被下游阻塞回压：写 Kafka 时 topic 分区打满、consumer 落后、broker 磁盘或网络告警；或流计算作业 checkpoint 长期失败，反压传回 source 使 binlog 消费暂停。可参考 AWS 博客中 Aurora MySQL binlog 下游消费处理方案 对下游消费压力的讨论。关键风险：停读期间 binlog 持续增长，一旦超过保留窗口，根因 4 会退化为根因 3。

判定方法：查看下游链路 lag 指标、broker 磁盘与网络 IO、消费端 GC 与重启记录；在流计算作业 UI 中查看 checkpoint 失败原因与 backpressure 状态（source 算子 busy 高、下游算子 backpressured 高即为回压传导）。

处理要点：从下游入手，扩容 topic 分区、增加消费者、修复慢 sink；可拉长 checkpoint interval 缓解频繁失败，但需注意这会放大重启后重放的数据量；对历史积压数据分批回放，避免追赶流量与新流量叠加。

三、处理步骤（建议按顺序执行）

1. 看监控曲线确认延迟起点：延迟是突增还是缓涨。突增多为发布 / 配置变更或下游故障，缓涨多为容量与反压。
2. 查作业日志定位第一处异常时间点，确认属于上述哪类根因。
3. 做连接侧检查：MySQL 会话超时参数、代理空闲超时、心跳是否开启。
4. 做格式与位点检查：binlog_format=ROW、binlog_row_image=full、binlog 保留时长、GTID 一致性（gtid_mode=ON、enforce_gtid_consistency=ON）。
5. 做反压检查：下游写入速率、分区分布、checkpoint 状态。
6. 恢复后验证：对比源库与下游位点差、抽样核对记录数与主键、确认 lag 曲线回落并保持稳定。

四、常用排查参数与命令

-- 超时与格式
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
SHOW VARIABLES LIKE 'net_write_timeout';
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';

-- GTID 与 binlog 保留
SHOW VARIABLES LIKE 'gtid_mode';
SHOW VARIABLES LIKE 'enforce_gtid_consistency';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';  -- MySQL 8.0.21+；旧版本为 expire_logs_days
SHOW BINARY LOGS;                                   -- 最老 binlog 与文件大小
SHOW MASTER STATUS;                                 -- 旧版本；8.4+ 用 SHOW BINARY LOG STATUS

流计算侧常见的三个检查项：execution.checkpointing.interval（拉长以减少频繁失败）、execution.checkpointing.timeout（区分检查点失败与作业反压）、sink 的写入并行度与批量大小。具体项以所用版本文档为准。

排查延迟时，监控曲线、运行日志与异常告警是定位延迟起点的第一手材料。例如袋鼠云 StreamWorks 以 Flink 为计算引擎，基于日志的全链路 CDC 可捕获 MySQL Binlog 变更并实时写入 Kafka、Hive 或湖仓，并提供 Metric 监控曲线、运行日志与异常告警，可把上述检查项收敛到同一运维界面完成。

五、常见失败模式

• 只重启不查位点：重启解决不了根因，还会在 binlog 已清理的情况下反复触发快照。
• 对已 purge 的位点强行续传：会直接失败或触发全量，应先按根因 3 的流程评估保留窗口。
• 快照与增量衔接处的重复：恢复快照后下游可能收到已存在记录，下游需按主键幂等，或先对账再放行。
• 误以为降低消费速率能缓解延迟：反压场景下减速只会让延迟更大，应先解决下游瓶颈。
• 心跳开启但中间代理仍断连：心跳只解决 CDC 连接自身的空闲判定，代理与防火墙的独立超时需要单独配置。

六、落地检查清单

• 延迟起点是否与一次发布、配置变更或下游故障对齐。
• wait_timeout、net_write_timeout 与中间代理超时是否大于 CDC 心跳周期。
• binlog_format 与 binlog_row_image 是否满足 ROW + full。
• binlog 保留时长是否大于最大允许停机时间（建议留 2～3 倍余量）。
• 下游 topic 分区与消费者数量是否支撑峰值写入。
• checkpoint 是否稳定，失败原因是超时还是反压。
• 恢复后是否完成位点差、记录数、主键抽样三项核对。

监控建议：对 source lag、binlog 保留余量（最老 binlog 文件时间）与下游写入速率设置告警，通常比只盯延迟数值更早发现问题。