DM从MySQL同步到TiDB，延迟从10秒增长到6小时且无法追上

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境
【TiDB 版本】v7.5.0
【部署方式】腾讯云CVM自建
【操作系统/CPU架构/芯片详情】CentOS 7.9 / x86_64
【机器部署详情】DM节点：8核32GB / TiDB节点：16核64GB / TiKV节点：16核64GB，SSD 2TB
【上游数据库】MySQL 8.0（AWS RDS），数据量约2TB
【集群数据量】下游TiDB约 1.8TB
【集群节点数】2 TiDB + 3 PD + 3 TiKV + 2 DM-worker
【问题复现路径】配置DM从AWS RDS MySQL同步到TiDB，起初同步延迟稳定在5-10秒。业务流量增长后（每天约3000万条DML），延迟逐步增大，到第5天时已达到6小时，且持续无法追上
【遇到的问题：问题现象及影响】下游TiDB数据实时性严重不足，业务依赖实时同步的查询结果不准确，部分报表展示的是6小时前的旧数据

2

看你的描述，延迟从10秒飙到6小时，大概率是DM的同步能力到了瓶颈，或者是下游TiDB写入遇到了热点/资源争抢。先按下面几步排查：

  1. 看DM监控：dmctl query-status 看下当前同步任务，重点看 relay 和 binlog 的 master-binlog 与 syncer-binlog 差距，确认是拉取慢还是写入慢。
  2. 检查DM-worker资源：8C32G可能不够，尤其是大事务或DDL时。
3

有两台 DM‑Worker；默认单 worker 回放线程数偏低。 上游 RDS 高并发 DML，如果大量更新缺少主键、索引，每一条 row‑binlog 执行都会触发全表扫描，单条事务回放耗时暴涨，回放吞吐量直接打垮。

MySQL binlog 为 ROW 格式，数据表缺少主键 / 合适索引是 DM 回放卡顿头号元凶

4

写入增大后 DM worker 应用跟不上：查 relay/binlog 位点、是否大事务、目标表索引过多、下游写入热点。处理：扩 DM worker、拆任务、过滤无关表、优化下游索引与批次；跨云注意带宽。持续扩大说明同步吞吐 < 源端 DML，需扩容或降源峰。