版本升级先看release notes的不兼容变更。
问题解决没？ 如何解决的？
GC safepoint 停滞不前进 → MVCC 旧版本无限堆积 → TiKV 后台 GC+Compaction 持续疯狂执行 → TiKV CPU 打满、IO 占用高 → 读写 SQL 扫描大量历史版本，延迟暴涨、集群整体压力飙升。
集群规格：36 TiKV、5 TiDB、5 PD，数据 78T，海量历史版本会放大 CPU 抖动。
日志显示GC任务重复跳过，优先排查长事务阻塞safe_point，再调compaction参数提速
是gc不推进。感觉和集群的压力有关。业务降读之后慢慢的恢复了，cpu也降下来了
是gc不推进。感觉和集群的压力有关。业务降读之后gc慢慢的恢复推进了，cpu也降下来了
没有找到大事务
gc life time 设置的1h
有可能，你当时集群的负载应该是很高的，slow store挺多，gc的优先级和其他调度相比可能比较低。
现在gc 往前面推进了？
大量备份流占用safe_point卡住GC，先停备份再手动推进safe_point缓解压力
那可能是集群压力大，优先处理业务了，gc临时暂停了
机器配置一样吗
分库分表迁移注意全局唯一ID生成方式。
ticdc没开
78T、多集群 GC 不推进是个典型且要尽快处理的问题——GC 卡住会导致 MVCC 旧版本堆积、TiKV 存储和 CPU 持续上涨、扫描变慢，恶性循环。GC 不推进最常见的原因是存在长时间未结束的事务或未清理的 GC safepoint 阻塞：1）先查阻塞点——SELECT * FROM mysql.tidb WHERE variable_name LIKE ‘%gc%’，看 tikv_gc_safe_point 和 tikv_gc_last_run_time 是否长时间不动；2）查是否有超长事务卡住 safepoint：看 INFORMATION_SCHEMA.CLUSTER_TIDB_TRX 和 DATA_LOCK_WAITS，以及是否有长期存在的 CDC/BR 备份任务或 stale 的 pump/drainer，这些都会持有 GC safepoint 不让推进；3）常见元凶还包括未关闭的 TiCDC changefeed、卡住的 BR 备份、或 tidb_gc_life_time 被设得过大。定位到阻塞的事务/任务后清理它，GC 就会恢复推进。恢复后旧版本清理会有一波额外 IO/CPU，注意在相对低峰观察。另外确认 tidb_gc_enable 是 ON、tidb_gc_run_interval 和 tidb_gc_life_time 配置合理。这个建议尽快查 safepoint 卡在哪，越拖存储和性能压力越大。
GC Safe Point 无法向前推进 → 旧版本 MVCC 数据无法被 GC 清理 → TiKV 底层 RocksDB 多版本数据膨胀、SST 文件暴增、读放大暴涨 → TiKV CPU（compaction + 读请求）持续拉高 → 用户 SQL 扫描、索引查询开销变大，业务 SQL 变慢、集群整体承压。