Canal客户端消费中断后，主库Binlog越积越多，是因为Canal Server模拟从库被动接收MySQL推送的binlog，一旦Client未及时ack，Server便停止请求新事件，而MySQL持续写入并滚动binlog文件，导致位点滞后、文件被覆盖或清理。
Canal客户端消费中断后，主库Binlog为什么会越积越多？
因为Canal Server本身不主动拉取binlog，而是靠MySQL主库“推送”——本质是模拟从库的IO线程。一旦下游Client（比如你写的Java应用）消费卡住、断连或没提交ack，Canal Server就会停止向MySQL请求新事件，但MySQL仍在持续写入binlog。久而久之，Canal还在读旧位点，而主库binlog文件不断滚动，mysql-bin.000012 → mysql-bin.000013 → ……最终触发ER_MASTER_FATAL_ERROR_READING_BINLOG或Could not find first log file name in binary log index file这类错误。
怎么快速定位是Client端导致的中断？
别先翻MySQL日志，直接看Canal Server的logs/canal/canal.log里有没有高频重复的以下几类ERROR：
-
com.alibaba.otter.canal.client.CanalConnector相关异常：如java.io.IOException: Connection reset by peer，说明Client侧主动断连或网络抖动 -
com.alibaba.otter.canal.protocol.exception.CanalClientException: ack error，代表Client发了ack但Server没收到或位点校验失败 -
no acknowledge for xxx seconds，Canal Server检测到Client长时间未提交ack，自动断开连接
再查Client进程是否存活：ps aux | grep your-canalsync-app；如果进程在，用jstack -l 看主线程是否卡在connector.getWithoutAck()或connector.ack()调用上。
Client端常见中断原因和修复动作
多数不是Canal配置问题，而是Client代码逻辑或资源瓶颈：
- 没做异常兜底：Client消费线程抛出
NullPointerException或OutOfMemoryError后静默退出，但进程没挂——表现为日志停更、无ERROR、CPU归零 - ack时机错乱：在业务处理完成前就调用了
connector.ack()，导致位点提前提交；后续处理失败时无法重试，Client重启后直接跳过这批数据，Server以为已消费完毕，不再推送 - batchSize设得过大：一次
getWithoutAck(1000)返回1000条，但Client解析+投递Kafka耗时超60秒，超过canal.instance.network.timeout（默认30秒），Server主动断连 - 没启用
autoAck且忘记手动ack：尤其在异步处理场景下，回调函数里没包一层try/finally { connector.ack() }，异常一出就漏ack
临时缓解可改小batchSize、加try/finally保ack；长期必须补全监控：对Client暴露/health端点，上报lastBatchGetTime、lastAckTime、pendingCount三项指标。
如何防止Binlog被主库自动清理掉？
MySQL默认只保留expire_logs_days=0（即不自动删）或7天的binlog，但Canal中断几小时就可能让当前位点落在被删文件里。必须立刻干预：
- 确认当前需要的最小位点：
show master status拿到File和Position，再查Canal Server的logs/example/meta.log或zk中/otter/canal/destinations/example/1001/cursor，对比两者是否一致 - 若发现
meta.log里的filename已不在show binary logs列表中，说明binlog丢失，只能走全量补偿 - 紧急保底：在MySQL上执行
SET GLOBAL expire_logs_days = 30（需SUPER权限），并写入my.cnf持久化；同时检查max_binlog_size是否过小（如100M），频繁切文件会加剧位点管理难度
真正棘手的是“Client卡在中间事务没ack，但Server又不敢推进位点”，这种状态不会报错，却会让binlog在磁盘上越堆越高——得靠pendingCount指标+定期show processlist查Canal连接状态来交叉验证。
