HDUO Lab

标签： Percolator

  • TiDB 集群 P99 暴涨至 5000ms：一个 2 亿行大事务 DELETE 引发的 Percolator 惨案

    某次排查过程中，核心交易集群的 TiDB 节点发生大面积 OOM，集群 P99 延迟从日常的 10ms 直接飙升到 5000ms 以上，TiKV 节点接连抛出 Server is busy 拒绝服务。先说最终结论： 某位研发在后台归档任务中，执行了一条没有任何 LIMIT 和分批的 DELETE 语句，企图在一个事务内删掉 2 亿行历史数据。由于对底层 Percolator 分布式事务模型一无所知，这个超级大事务不仅瞬间抽干了 TiDB Server 的内存，残留在 TiKV 的海量锁和 MVCC 墓碑（Tombstone）更是直接引发了读写雪崩。

    案发现场：从 OOM 到全局雪崩

    监控面板上，故障的爆发几乎是垂直的：

    1. tidb_server_memory_usage 指标在 3 分钟内从 4GB 飙升到 64GB（容器 Limit），随后节点被内核 OOMKilled。

    2. TiKV 的 Raft apply duration P99 飙到秒级，Coprocessor CPU 打满。

    3. 应用端出现大量 java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction 和 Region is unavailable。

    切到机器上抓一下 dmesg，典型得不能再典型的 OOM：

    [123456.789] Memory cgroup out of memory: Kill process 5678 (tidb-server) score 1980 or sacrifice child
[123456.790] Killed process 5678 (tidb-server) total-vm:85934028kB, anon-vm:67108864kB, file-vm:0kB, shmem-vm:0kB

    翻看 INFORMATION_SCHEMA.SLOW_QUERY 和存活节点的 TiDB 日志，抓到了罪魁祸首：

    DELETE FROM trade_orders WHERE create_time < '2023-01-01 00:00:00';

    就是这么一句平平无奇的 SQL，命中了近 2 亿条数据。

    当我拿着这条 SQL 去找对应业务线的开发时，得到的答复是：“我们用的是分布式数据库啊，底层不是无限水平扩展的吗？删个历史数据怎么就挂了？”

    这种把分布式数据库当成魔法、完全无视底层物理定律的想法，是导致大多数生产灾难的根源。分布式 != 无底洞。

    刨根问底：为什么分布式数据库最怕“大事务”？

    在单机 MySQL (InnoDB) 中，大事务会撑爆 Undo Log，导致长事务阻塞和主从延迟。而在 TiDB 这类基于 Percolator 模型的分布式 HTAP 数据库中，大事务的杀伤力是指数级的。

    1. OOM 的元凶：两阶段提交（2PC）的内存缓冲

    TiDB 处理事务使用的是 Percolator 模型的变种。在事务提交（Commit）之前，客户端（即 TiDB Server）会把所有修改的数据缓存在自己的内存中。 当执行这句 2 亿行的 DELETE 时，TiDB Server 需要将这 2 亿个 Key 的修改操作（在底层，DELETE 也是一种写入，即写入包含 Tombstone 标记的 KV）装进内存。 算一笔最简单的账：单行数据的 Key + Value 加上事务元数据假设为 200 Byte。 200,000,000 * 200 Byte ≈ 40 GB。 更要命的是，Go 语言在处理如此庞大的对象分配时，GC 会产生巨大的开销，内存碎片加上堆栈扩展，轻轻松松就能把 64GB 的容器内存干爆。

    2. “掩耳盗铃”的配置修改

    其实 TiDB 为了防止这种惨案，出厂设置是有保护机制的：txn-total-size-limit 默认通常为 100MB。 理论上，这个事务早就该报 Transaction too large 失败了。但我查阅配置变更历史时发现，前段时间该业务线抱怨过几次批量更新报错，某位缺乏敬畏之心的运维，直接将全网的 txn-total-size-limit 改成了 10GB！ 放开这种硬性防御阈值，等于拆掉了保险丝。TiDB 成功绕过了配置限制，然后死在了物理内存耗尽上。

    3. 锁残留与 Resolve Lock 风暴

    TiDB Server OOM 崩溃后，灾难并没有结束。 在 Percolator 2PC 的 Prewrite 阶段，TiDB 会在 TiKV 端写入大量的 Primary Lock 和 Secondary Lock。TiDB Server 进程猝死，导致这些锁变成了“孤儿锁”。 此时，正常的业务请求如果读取到了这些被锁住的 Key，就会发现事务处于 Pending 状态。为了保证 ACID，读请求必须触发锁清理机制（Resolve Lock）。 几十万个并发查询撞上几千万个残留锁，瞬间引发了海量的 RPC 交互：

    [WARN] [endpoint.go:612] ["error response"] [err="Key is locked (primary)"] 
[WARN] [resolve.go:128] ["resolve lock timeout"] [txn=43981293847123984]

    TiKV 的 RPC 线程池直接打满，Raftstore 处理缓慢，最终导致大面积的 Region unavailable，连正常的小事务也无法提交。

    终极解法与避坑指南

    对于分布式数据库的批量数据清理，绝对不能用传统的“大事务一波流”。如果你需要删几亿条数据，请把“防御性编程”刻在脑子里。

    正规的落地姿势有三种：

    方案 A：非事务 DML（Non-transactional DML） 新版 TiDB 提供了原生的批处理语法，直接在内部完成分批提交，不保证事务的原子性（反正删历史数据也不需要原子性），彻底绕过大事务限制：

    BATCH ON id LIMIT 10000 
DELETE FROM trade_orders WHERE create_time < '2023-01-01 00:00:00';

    方案 B：按时间分区的 Drop Partition 对于日志流、流水表，建表时就应该规划好时间分区（Partition By Range）。清理历史数据只需一条 ALTER TABLE trade_orders DROP PARTITION p2022;。这在底层仅仅是元数据的解绑，瞬间完成，没有 MVCC，没有锁冲突。

    方案 C：TiDB TTL (Time to Live) 机制 如果业务特性允许，直接在表结构上加上 TTL 属性：

    ALTER TABLE trade_orders TTL = `create_time` + INTERVAL 1 YEAR;

    交由 TiDB 后台按 Region 慢慢清理，对前台业务透明。

    排查清单：同类大事务问题速查 (Troubleshooting Checklist)

    1. 核对 OOM 与系统日志 立刻在 TiDB 节点执行 dmesg -T | grep -i oom，如果命中 tidb-server，说明发生过严重的内存挤兑，大概率是大事务或者无索引的巨型 JOIN。

    2. 定位元凶 SQL 检索 INFORMATION_SCHEMA.SLOW_QUERY，重点关注 Mem_max、Txn_start_ts 和 Query_time 极大的语句： SELECT query, mem_max, process_time FROM information_schema.slow_query ORDER BY mem_max DESC LIMIT 5;

    3. 检查全局限制配置 不要盲目调大保护参数。检查 tidb_mem_quota_query（单条 SQL 内存限制）和 txn-total-size-limit（总事务大小限制），恢复到合理阈值（推荐单事务不要超过 1GB）。

    4. 清理遗留的悲观锁/乐观锁 如果 OOM 后集群持续卡顿，观察 Grafana 中的 TiKV-Details -> Locks 面板。必要时可通过临时调低 resolve-lock 的 backoff 时间来加速孤儿锁清理，或联系官方辅助清理陈旧的 MVCC tombstone 触发手动 Compaction。

    分布式架构给了你海量存储的错觉，但底层的内存、网络 IO 和锁机制依然遵循着严密的物理约束。在生产环境敲下回车之前，想想底层要付出多大的代价。