MySQL Binlog采集突然延迟5分钟——Canal卡住了怎么排查？

Canal采集Binlog延迟，是几乎每个做CDC同步的团队都会撞上的问题。之前做用户支付实时大盘的时候，早高峰一上来就延迟报警，5分钟数据卡住不动，下游Hologres看板的成交GMV直接停在原地。这道题面试官想听的不是"重启Canal"，而是你有没有一套排查思路，能从源头到下游一层一层定位。

业务场景：早高峰GMV看板停摆

当时的链路是 MySQL（订单库）→ Canal → Kafka → Flink → Hologres，业务高峰QPS大概5000，订单表binlog每秒约2MB。那天上午9点05分，运营群里有人喊："GMV不动了！"打开Canal admin一看，delay直接飙到280秒并且还在涨。

# 1) Canal admin metrics接口看delay（毫秒）和当前消费位点
curl http://canal-admin:8089/api/v1/canal/canalCluster/instances
 
# 2) MySQL端查最新Binlog位点，跟Canal的position对比
mysql> SHOW MASTER STATUS;
+------------------+-----------+
| File             | Position  |
+------------------+-----------+
| mysql-bin.001234 | 587326441 |  -- 最新位点
+------------------+-----------+
 
# 3) Canal当前消费到哪：差异越大说明落后越多
# meta.dat里记录的是 mysql-bin.001231 / 12387645 → 落后了3个文件
 
# 4) Canal Server GC日志
tail -f /home/admin/canal-server/logs/canal/canal_stdout.log | grep -E 'Full GC|OutOfMemory'

一对位点立刻看出来：Canal落后了将近3个Binlog文件。再去看Canal日志，发现parser线程没有异常但下游sink到Kafka的batch一直在retry，原来Kafka某个broker磁盘报警限速了，把Canal反压住了。

根因一：上游Binlog突然激增

最常见的场景是业务方半夜跑批，一条SQL update一百万行，瞬间产生几个GB的Binlog。Canal单parser线程拉不过来就开始堆积。判断方法很直接：看MySQL的Binlog文件增长速度。

# 看最近1小时Binlog文件大小变化（每个mysql-bin文件默认1G）
ls -lh /var/lib/mysql/mysql-bin.* | tail -20
 
# 平时1小时1-2个文件，激增时可能1小时10+个文件
# 进一步查是哪张表：用mysqlbinlog解析
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.001234 \
  | grep -E '^### (UPDATE|INSERT|DELETE)' | awk '{print $3}' \
  | sort | uniq -c | sort -rn | head
 
# 输出示例：某张表占了90%的binlog量
# 380000 `order_db`.`order_item`
#   2100 `order_db`.`order_main`

应对：跟业务约定大批量update必须分批小事务，避免一条SQL刷百万行；Canal侧在instance.properties把parser的ringbuffer调大（canal.instance.memory.buffer.size从16384调到65536）。

根因二：下游消费/写入慢导致反压

Canal本身只是搬运工，真正瓶颈往往在下游Kafka或者直连的MQ上。我们这次就是Kafka broker磁盘满80%触发限速。

# canal到kafka的关键参数（instance.properties）
canal.mq.flatMessage = true              # 是否JSON扁平化（影响吞吐）
canal.mq.canalBatchSize = 50             # 一次拉多少条binlog
canal.mq.parallelThreadSize = 8          # 并行写kafka的线程数（默认1，要调）
canal.mq.partitionsNum = 12              # topic分区数对应
canal.mq.partitionHash = .*\\..*:$pk$  # 按主键hash保证同主键有序
 
# Kafka producer侧
canal.mq.producer.batch.size = 524288   # 512KB攒批
canal.mq.producer.linger.ms = 100       # 攒100ms再发
canal.mq.producer.compression.type = lz4 # 必开压缩