Flink CDC 建好了却同步不出数据:别等作业跑起来才发现 binlog 没开

Flink CDC(底层 Debezium)做 MySQL 到数据湖的实时同步,有一类最费人的失败:配置全对、作业保存成功、集群正常拉起、初始全量快照也顺利跑完——切到增量阶段才挂。因为读 binlog 是增量阶段才真正开始的事,源库根本没开 binlog、或格式不对,前面每一步都发现不了。

此时 Flink 集群已经申领、资源配额已经占用、全量快照白跑一遍,排查还要从一堆 Debezium 堆栈里往回找。这篇给出一张接 CDC 之前的源库体检清单,以及「我的数据空间」(能力页)把这张清单产品化成两道闸的做法。

一、失败越晚,成本越高

CDC 链路上每个失败点的代价是递增的:

保存时拒绝,用户 3 秒改完重试;增量阶段才失败,中间隔着集群冷启动、全量快照、若干分钟到几小时——校验能前置一步,就前置一步。

二、源库体检清单(MySQL)

检查项	怎么查	要求	不满足时的典型表现
binlog 开关	SHOW VARIABLES LIKE 'log_bin'	ON	Debezium 报 The MySQL server is not configured to use a binlog
binlog 格式	SHOW VARIABLES LIKE 'binlog_format'	ROW	STATEMENT/MIXED 读不到行级变更,增量静默无数据或直接报错
行镜像	SHOW VARIABLES LIKE 'binlog_row_image'	FULL	MINIMAL 时 UPDATE/DELETE 缺前镜像,下游合并出错
复制权限	账号需 REPLICATION SLAVE, REPLICATION CLIENT, SELECT	三者齐	Access denied; you need ... REPLICATION SLAVE privilege
server-id	连接器侧配置	与源库及其它复制客户端不冲突	A slave with the same server_uuid/server_id ... 互踢
binlog 保留	binlog_expire_logs_seconds	大于最长快照耗时	大表快照跑完,起点位点已被清,增量起不来

前四项是硬前提,后两项是大表/多任务场景的隐性坑。云上 RDS 通常默认 ROW + FULL,自建 MySQL 则大概率要自己开。

三、产品化:同一套校验,布两道闸

清单靠人自觉执行是不可靠的,平台把它做成了两道闸:

第一道:向导里选完源库,立即探测。 用户选定源 MySQL 的那一刻,后端真实连一次源库,查 log_bin / binlog_format,不满足直接在表单上弹出明确告警并挡住提交——不用等填完十几个字段才知道白填了。

第二道:保存接口 fail-closed 收口。 前端校验永远可以被绕过(直调 API),保存时后端再做同一套校验,任一项不满足、或源库连不上,一律拒绝保存。宁可挡住一次可疑的保存,也不放一个注定失败的作业进调度。

一个有意思的取舍:复制权限没有放进自动探测。SHOW GRANTS 的输出格式跨版本、跨云厂商差异很大,解析判定的误判风险高于漏判收益——这项留给 Debezium 启动时用原生报错说话,清单里靠文档提示。自动化校验的边界感很重要:只自动化「判定绝对可靠」的项,拿不准的宁可交给权威组件报错。

另一个顺手的设计:源库的连接凭证不进 Flink SQL——由引擎侧连接器在运行时凭作业令牌回调平台现取,密码不落 SQL 语句、不进 JobManager/TaskManager 日志。

闸放行之后,链路在平台里长这样:

四、三句话总结

• CDC 的失败点越靠后代价越高,「连接器协议对」不等于「这个实例真能做 CDC」,binlog 前提要在保存前真连源库探测;
• 校验布两道:交互侧即时反馈,保存侧 fail-closed 收口,前端校验永远不算数;
• 只自动化判定绝对可靠的检查项,格式不稳的(如 SHOW GRANTS)交给权威组件的原生报错。

---

这条 MySQL → 数据湖的实时同步链路是「我的数据空间」的一部分——一套可私有化部署的数据平台,支持 OEM 合作。看能力页与核心能力总览,交流合作 QQ:1559851993。