grafana监控GC gc_safe_point未推进

TiDBer_39v3800o · 2025 年5 月 22 日 14:32

【TiDB 使用环境】生产环境
【TiDB 版本】V7.1.0
【操作系统】centos7.9
【部署方式】物理机
【集群数据量】41T
【集群节点数】14
【问题复现路径】重启tidb集群
【遇到的问题：问题现象及影响】tidb grafana监控查看GC safe point未正常推进
PD记录的safe point
curl http://<PD_IP>:<PD_PORT>/pd/api/v1/gc/safepoint
“gc_safe_point”: 455470299584135176

TiDB记录的safe point

SELECT * FROM mysql.tidb WHERE variable_name=‘tikv_gc_safe_point’;
| tikv_gc_safe_point | 20250522-21:37:24.208 +0800 | All versions after safe point can be accessed. (DO NOT EDIT)

TiKV各节点状态

tiup ctl:v<CLUSTER_VERSION> tikv --host=<TiKV_IP>:<TiKV_STATUS_PORT> metrics | grep gc_safe_point

HELP tikv_gcworker_autogc_safe_point Safe point used for auto gc

TYPE tikv_gcworker_autogc_safe_point gauge

tikv_gcworker_autogc_safe_point 455470299584135200
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.005”} 706
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.01”} 710
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.025”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.05”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.1”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.25”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“1”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“2.5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“10”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“+Inf”} 713
tikv_pd_request_duration_seconds_sum{type=“get_gc_safe_point”} 1.0915107170000005
tikv_pd_request_duration_seconds_count{type=“get_gc_safe_point”} 713

三方safe point不一致

PD记录：455470299584135176（2025-01-22左右）
TiDB记录：20250522-21:37:24.208 +0800（2025-05-22）
TiKV记录：455470299584135200（与PD接近）
*通过GRAFANA查看与PD结果也一致，一致未推进

image1827×727 131 KB

通过tidb日志查看GC是有正常推进的

image1525×767 118 KB

期间有重启tidb集群和重启tidb server节点都无用

Billmay表妹 · 2025 年5 月 23 日 02:27

TiDB 中 GC Safe Point 不推进问题的分析与解决方案

一、TiDB 垃圾回收机制和 GC Safe Point 工作原理

1.1 垃圾回收机制概述

TiDB 采用多版本并发控制(MVCC)机制来管理数据版本。当数据被更新或删除时，旧版本数据不会立即被物理删除，而是与新版本一起保留，通过时间戳区分不同版本。垃圾回收(GC)机制负责清理这些不再需要的历史版本数据，释放存储空间。

1.2 GC 工作流程

TiDB 集群中会选出一个 TiDB 实例作为 GC Leader，负责协调整个 GC 过程。GC 默认每 10 分钟触发一次，主要包含三个步骤：

解决锁(Resolve Locks): 扫描并清除 safe point 之前的所有锁。
删除范围(Delete Ranges): 快速清理由 DROP TABLE/DROP INDEX 等操作产生的整块数据。
执行 GC(Do GC): 各 TiKV 节点扫描数据，删除每个键不再需要的旧版本。

1.3 GC Safe Point 的定义与作用

GC Safe Point 是一个时间戳，表示 GC 可以安全删除的时间点界限。任何早于该时间点的数据版本(如果不是该键的最新版本)都可以被安全删除。Safe Point 的计算公式为：

Safe Point = 当前时间 - GC 生命周期(默认10分钟)

系统会确保 Safe Point 不会超过当前正在进行的任何事务的开始时间(start_ts)，以保证这些事务能够正常读取所需的历史数据。

通过系统变量 tidb_gc_safe_point 可以查看当前的 GC Safe Point 时间戳。

二、GC Safe Point 不推进的常见原因

2.1 长时间运行的事务

长时间运行的事务是导致 GC Safe Point 不推进的最常见原因之一。由于 GC Safe Point 不能超过任何活跃事务的开始时间，因此当存在长时间运行的事务时，GC Safe Point 会被阻塞在该事务的开始时间点。

2.2 TiCDC 或备份任务

TiCDC(TiDB Change Data Capture)或备份任务需要读取历史数据，因此也会阻止 GC Safe Point 推进。TiCDC 在 Normal、Stopped、Warning 或 Failed 状态下可能会暂时阻止垃圾回收过程。

2.3 GC 进程异常

GC Leader 节点可能因故障、网络隔离或其他原因而无法正常工作，导致 GC 进程无法正常执行，从而阻止 Safe Point 推进。

2.4 大规模数据操作

大规模的数据删除操作可能会导致 GC 处理压力增大，影响 GC 进度：

当执行大量 DELETE 操作时，TiDB 只是将数据标记为待删除状态，实际删除工作由 GC 完成。
如果删除操作非常大，可能会导致 GC 处理速度变慢，影响 Safe Point 推进。

2.5 系统参数设置不当

如果 tidb_gc_life_time 设置过长或 tidb_gc_enable 被禁用，也会导致 GC Safe Point 不推进或推进缓慢。

三、诊断和解决 GC Safe Point 不推进问题

3.1 诊断步骤

3.1.1 检查当前 GC 状态

SHOW GLOBAL STATUS LIKE 'tidb_gc%';

这将显示 GC 的最后运行时间、Leader 信息和当前 Safe Point。

3.1.2 检查 Safe Point 历史记录

SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point';

如果 Safe Point 长时间没有更新，说明 GC 存在问题。

3.1.3 检查长时间运行的事务

ADMIN SHOW SLOW;  -- 查看慢查询
SHOW PROCESSLIST;  -- 查看当前会话

通过这些命令可以识别可能阻止 GC 推进的长时间运行的事务。

3.1.4 检查 TiCDC 任务状态

如果集群配置了 TiCDC，检查 TiCDC 任务是否正常运行：

cdc cli changefeed list --pd=http://127.0.0.1:2379

3.1.5 检查 GC 相关日志

检查 TiDB 和 TiKV 日志中与 GC 相关的错误或警告信息：

grep "gc" /path/to/tidb.log
grep "gc" /path/to/tikv.log

3.2 解决方案

3.2.1 处理长时间运行的事务

识别并终止长时间运行的事务：

KILL [CONNECTION_ID];

对于必须长时间运行的事务，考虑将其拆分为多个较小的事务。

3.2.2 调整 GC 生命周期

如果需要更频繁的 GC，可以调整 tidb_gc_life_time 系统变量：

SET GLOBAL tidb_gc_life_time = '10m0s';  -- 默认值为10分钟

3.2.3 手动触发 GC

在特殊情况下，可以考虑手动触发 GC：

SET GLOBAL tidb_gc_enable = true;
SET GLOBAL tidb_gc_run_interval = '10m0s';

3.2.4 重启 GC Leader

如果 GC Leader 出现问题，可以考虑重启该 TiDB 节点，让系统重新选举 GC Leader。

3.2.5 调整 TiCDC 配置

如果 TiCDC 阻止了 GC Safe Point 推进，可以考虑调整 TiCDC 配置或暂时停止 TiCDC 任务，让 GC 完成。

四、最佳实践和预防措施

4.1 监控 GC 状态

设置监控系统，定期检查 GC Safe Point 的推进情况，可以使用 Prometheus 和 Grafana 监控以下指标：

tikv_gc_safe_point
tikv_gc_last_run_time
tikv_gc_leader_desc

4.2 避免长时间运行的事务

将大事务拆分为多个小事务
设置合理的事务超时时间
优化查询性能，减少事务执行时间

4.3 合理规划大规模数据操作

将大批量删除操作拆分为多个小批量操作
选择系统负载较低的时间执行大规模数据操作
考虑使用 LIMIT 子句限制每次操作的数据量

4.4 定期检查系统参数

确保 tidb_gc_enable 设置为 true
根据业务需求合理设置 tidb_gc_life_time
检查 tidb_gc_run_interval 是否设置合理

4.5 存储空间监控

定期监控存储空间使用情况，及时发现异常增长，可能预示着 GC 问题：

SELECT 
    TABLE_SCHEMA, 
    TABLE_NAME, 
    DATA_LENGTH + INDEX_LENGTH AS total_size
FROM 
    information_schema.TABLES 
ORDER BY 
    total_size DESC 
LIMIT 10;

4.6 定期检查 TiKV 压缩情况

TiKV 的压缩(Compaction)过程会影响 GC 的效率，定期检查 TiKV 的压缩状态：

pd-ctl region compact-status

总结

TiDB 的 GC Safe Point 不推进问题可能由多种因素导致，包括长时间运行的事务、TiCDC 任务、GC 进程异常等。通过本文提供的诊断步骤和解决方案，可以有效识别和解决这些问题。同时，采取适当的预防措施，如监控 GC 状态、避免长时间运行的事务、合理规划大规模数据操作等，可以降低 GC Safe Point 不推进问题的发生概率，保证 TiDB 集群的稳定运行和存储空间的有效利用。

TiDBer_39v3800o · 2025 年5 月 23 日 02:38

都有检查过，tidb server的GC是有正常推进的。PD、TIKV的GC未正常推进