生产 TiDB 运维灵魂三问，欢迎交流经验 正文：

🪐 TiDB 技术问题
1

结合日常运维工作，提三个实战问题，欢迎各位大佬解答、补充：

  1. 如何快速定位 TiKV CPU 飙升的根因？
  2. 业务出现大量 Region 热点，除了打散数据还有哪些解法？
  3. TiCDC 同步延迟过高，常规排查步骤是什么？
2

范围很大啊,tikv cpu飙升主要还是先看dashboard中的topsql里面看看cpu使用情况;region热点问题主要还是业务设计,将id随机生成

1 个赞
3

第二点我理解不太好打散，tidb只能按照range进行分片，自增分片键避免不了热点写。

4
  • 先判根因分类：查看 checkpoint lag 指标，区分上游 TiKV 阻塞、CDC 内部处理瓶颈、下游写入瓶颈三类。
  • 上游排查：核查 TiKV resolved_ts 推进、长事务与大事务、region 心跳异常。
  • CDC 侧排查：检查 sorter 内存溢出、任务调度负载、changefeed 参数配置。
  • 下游排查：核查下游库 IO、连接数、写入并发与事务回放压力。
  • 收尾优化：按对应瓶颈调整参数、拆分任务、整改业务 SQL。
6

DM 的全量同步基于 dump/load 模式，增量同步基于 binlog 拉取和回放。增量延迟的本质是 binlog 消费速度跟不上生产速度，常见瓶颈在 worker 线程数、目标库写入能力、或者网络带宽。建议先看 dm_worker 的 metrics。

7

DM 的全量同步基于 dump/load 模式，增量同步基于 binlog 拉取和回放。增量延迟的本质是 binlog 消费速度跟不上生产速度，常见瓶颈在 worker 线程数、目标库写入能力、或者网络带宽。建议先看 dm_worker 的 metrics。

8

DM 的全量同步基于 dump/load 模式，增量同步基于 binlog 拉取和回放。增量延迟的本质是 binlog 消费速度跟不上生产速度，常见瓶颈在 worker 线程数、目标库写入能力、或者网络带宽。建议先看 dm_worker 的 metrics。

9

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。