CDC 报找不到 binlog 文件
CDC 或复制断链最典型的报错是找不到所需的 binlog 文件（例如提示在 binary log index 中找不到首个日志文件）。根因多为三种：保留期太短导致位点落后于清理点、有人手工执行了 PURGE、主库切换后位点对不上。处理顺序是先核对文件是否真的不在，再决定是补位点续采还是重建快照——后者成本高得多。
基本信息
| 常见根因 | 保留期不足、手工 PURGE、主库切换后位点对不上 |
|---|---|
| 第一步核对 | SHOW BINARY LOGS 确认目标文件是否仍在 |
| 恢复选项 | 文件仍在则补位点续采；已清理则重做快照重建链路 |
| 善后动作 | 调整保留期，并补上位点滞后监控 |
典型使用场景
- 链路突然中断：先看报错里的文件名是否还在清单中
- 主从切换后：确认位点是否需要重新对齐
- 误清理复盘：有人手工删日志导致链路断掉
- 长假期结束：位点落后超过保留窗口的典型场景
- 新建链路验收：验证断链后的恢复流程是否真的可用
断链后的核对动作
断链后的核对动作
SHOW BINARY LOGS; -- 当前保留的 binlog 文件清单
SHOW MASTER STATUS\G -- 当前写入位点（8.4+ 改为 SHOW BINARY LOG STATUS）核对与决策
| 现象 | 含义 | 处理 |
|---|---|---|
| 目标文件仍在清单中 | 位点本身没有问题 | 补位点后继续消费 |
| 目标文件已不存在 | 已被清理，无法续采 | 重做快照重建链路 |
| 最早文件晚于位点时间 | 位点已经过期 | 必须重建 |
| 主库切换后位点无效 | 新主库日志序列不同 | 按新主库位点重新定位 |
重建快照成本很高（全量导出加追平时间），先用成本最低的方式核对文件是否真的不在，再决定恢复路径，避免白白浪费一次全量窗口。
恢复之后只把保留期调长是不够的：位点滞后监控必须一起补上，否则下一次长假期或大故障会以同样的方式复发。