Flink CDC(底层 Debezium)做 MySQL 到数据湖的实时同步,有一类最费人的失败:配置全对、作业保存成功、集群正常拉起、初始全量快照也顺利跑完——切到增量阶段才挂。因为读 binlog 是增量阶段才真正开始的事,源库根本没开 binlog、或格式不对,前面每一步都发现不了。此时 Flink 集群已经申领、资源配额已经占用、全量快照白跑一遍,排查还要从一堆 Debezium 堆栈里往回找。这篇给出一张接 CDC 之前的源库体检清单,以及「我的数据空间」(datastudiohappy.cn)把这张清单产品化成两道闸的做法。一、失败越晚,成本越高CDC 链路上每个失败点的代价是递增的:保存时拒绝,用户 3 秒改完重试;增量阶段才失败,中间隔着集群冷启动、全量快照、若干分钟到几小时——校验能前置一步,就前置一步。二、源库体检清单(MySQL)检查项怎么查要求不满足时的典型表现binlog 开关SHOW VARIABLES LIKE log_binONDebezium 报The MySQL server is not configured to use a binlogbinlog 格式SHOW VARIABLES LIKE binlog_formatROWSTATEMENT/MIXED 读不到行级变更,增量静默无数据或直接报错行镜像SHOW VARIABLES LIKE binlog_row_imageFULLMINIMAL 时 UPDATE/DELETE 缺前镜像,下游合并出错复制权限账号需REPLICATION SLAVE, REPLICATION CLIENT, SELECT三者齐Access denied; you need ... REPLICATION SLAVE privilegeserver-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 合作。产品介绍:https://datastudiohappy.cn/。