HDUO Lab

分类： 数据库运维与架构

  • 深入 TiDB 读延迟雪崩排查：长事务阻塞 GC 引发 MVCC 堆积与 TiKV Coprocessor OOM 惨案

    某次排查过程中，业务反馈核心交易链路上游频繁报超时（Timeout），监控显示整个 TiDB 集群的查询 P99 延迟从平时的 8ms 暴涨至 6000ms 以上，紧接着监控告警触发：多个 TiKV 节点相继 OOM 重启，集群陷入雪崩状态。

    不绕弯子，直接抛出排查结论：某业务研发绕过数据平台，使用客户端直连线上核心 OLTP 集群，开启了一个长事务执行极其复杂的分析型查询，且中途因客户端崩溃导致连接处于“Sleep”挂起状态长达 14 个小时未提交。

    根据 TiDB 基于 Percolator 模型的 MVCC 原理，为了保证该长事务的可重复读（Repeatable Read），全局 GC（Garbage Collection）的 Safepoint 被强行锁死在此事务的 start_ts，无法向前推进。导致的结果是：核心交易表产生的数千万次 Update/Delete 产生海量的历史版本（Tombstone）无法被清理。正常的单行主键查询被下推到 TiKV Coprocessor 后，底层的 RocksDB Iterator 被迫扫描成千上万个废弃版本数据才能找到最新记录，读放大呈指数级飙升，直接打满 Coprocessor 线程池并耗尽了 TiKV 的物理内存。

    案发现场与暴力干预

    当时接手排查时，现象非常诡异。慢查询日志里并没有突发的大流量，所有的正常交易 SQL（哪怕是主键 SELECT）都慢得令人发指。登录故障所在的 TiKV 宿主机查看现场：

    # dmesg -T | grep -i oom
[xxx] Out of memory: Killed process 12345 (tikv-server) total-vm:42949672960kB, anon-rss:32145678kB, file-rss:0kB, shmem-rss:0kB

    TiKV 已经被内核 OOM-Killer 献祭。查看 Grafana 监控 TiKV-Details -> Coprocessor Detail -> Total Ops Details，发现底层的 Scan 和 Next 操作次数飙升了近万倍；同时 TiKV-Details -> Thread CPU -> Coprocessor CPU 直接画了一条顶格的直线。

    经验直觉告诉我，这不是 SQL 索引没建好，而是底层存储引擎在“负重前行”。立即查看 GC 状态：

    SELECT * FROM mysql.tidb WHERE variable_name IN ('tikv_gc_safe_point', 'tikv_gc_last_run_time');

    果然，tikv_gc_safe_point 的时间戳停留在十几个小时前。

    找出罪魁祸首的命令很简单，拉取全集群执行时间超过 1 小时的长事务：

    SELECT INSTANCE, ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO 
FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST 
WHERE TIME > 3600 ORDER BY TIME DESC;

    抓到一个 TIME 高达 50000+ 秒的 Sleep 连接。没有任何犹豫，直接 KILL TIDB 斩断该连接。

    大约等待了 5 分钟（GC 重新计算 Safepoint 并开始后台清理），TiKV 的 CPU 使用率断崖式下跌，P99 延迟回归 10ms 以内，报警全部解除。

    底层原理解析：为什么一个挂起的连接能搞挂整个集群？

    很多人把 TiDB 当作单机 MySQL 来用，缺乏对分布式 MVCC 机制的敬畏。在 Percolator 事务模型中，任何数据的更新（Update）和删除（Delete）本质上都是写入一条带有新时间戳（commit_ts）的记录，而非就地修改。

    为了防止磁盘被无尽的历史版本撑爆，TiDB 后台有一个 GC Leader 节点，定期（默认 10 分钟）推进 Safepoint，并通知 TiKV 清理掉 Safepoint 之前的旧版本。

    但这里有一个极其致命的硬性约束：Safepoint 的推进绝对不能超过集群中当前正在运行的最老事务的 start_ts。如果不加这个限制，长事务在执行中途，其依赖的老版本数据被 GC 提前清理掉了，就会报出著名的 GC life time is shorter than transaction duration 错误。

    当出现一个几小时不提交的僵尸事务时，GC Safepoint 被迫停滞。我们看看底层的读放大是怎么产生的：

    在 TiKV 侧，数据存储在 RocksDB 中。当你执行 SELECT * FROM table WHERE id = 1 时，Coprocessor 会构造一个 RocksDB Iterator 并在该键值区间进行 Seek，然后不断调用 Next() 往下扫。 正常情况下，扫到最新的有效记录就返回了。但由于 GC 停滞，该行数据如果经历了 10 万次高频更新，RocksDB 里就会存在 10 万个带有不同版本号的旧数据。Iterator 必须强行越过（遍历）这 10 万个逻辑删除标识（Tombstone），最终把数据拼装返回。

    这就导致了：

    1. CPU 爆炸：无休止的 Next() 调用榨干了 Coprocessor CPU。

    2. OOM 惨案：读取海量垃圾版本导致 Block Cache 被频繁换入换出（Thrashing），内存中驻留了大量无用的多版本数据结构，直至突破 memory-usage-limit 防线引发 OOM。

    防御性配置与避坑指南

    把这种“一粒老鼠屎坏了一锅汤”的风险暴露在默认配置下，是极度危险的运维架构。要想在生产环境中活得久，必须在服务端建立防御机制。

    1. 全局只读事务超时熔断 严格限制单个查询的最长执行时间，超过阈值由服务端主动掐断。

    -- 设置全局 SQL 超时时间为 30 分钟（毫秒计算）
SET GLOBAL max_execution_time = 1800000;

    2. OOM 防御：单次查询内存硬限 防止垃圾 SQL 或者深层无索引 JOIN 直接撑爆 TiDB 节点的内存。

    -- 限制单条 SQL 占用最大内存为 4GB
SET GLOBAL tidb_mem_quota_query = 4294967296;
-- 配置超过配额时的行为为 CANCEL（直接熔断报错）
SET GLOBAL tidb_oom_action = 'CANCEL';

    3. 长时间空闲连接杀手（Idle Timeout） 对于文中这种事务开启后客户端挂死导致的 Sleep 状态，必须通过空闲超时来兜底：

    -- 断开空闲时间超过 3600 秒的交互式连接
SET GLOBAL interactive_timeout = 3600;
SET GLOBAL wait_timeout = 3600;

    4. 架构隔离：HTAP 的正确打开方式 永远不要在 OLTP 的存储节点（TiKV）上跑重度分析型查询。如果业务确实需要拉取全表进行长周期聚合分析，必须通过 TiFlash 列存引擎进行物理隔离。利用 set @@session.tidb_isolation_read_engines = "tiflash"; 强行将耗时分析路由到 TiFlash，保护核心交易链路。

    排查清单 (Troubleshooting Checklist)

    1. 读延迟剧增且 CPU 打满：如果整体 QPS 平稳但 P99 飙升，首查 Grafana TiKV-Details -> Coprocessor -> Total Ops Details 中 Next 调用次数是否异常放大。

    2. 确认 GC 状态：查询 mysql.tidb 表中的 tikv_gc_safe_point，对比当前系统时间，若滞后超过 1 小时，必有长事务或死锁阻塞。

    3. 定位僵尸事务：使用 SELECT * FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST WHERE TIME > N 定位超长事务，必要时立刻 KILL TIDB。

    4. 验证 MVCC 版本堆积度：通过 pd-ctl 或者慢查询日志中 Total_keys 与 Process_keys 的比值来判断读放大比例，若 Total_keys 远大于 Process_keys，说明扫描了大量废弃历史版本。