PingCAP MetricsTool
等所有 监控全是打开状态, 并渲染出图像后, 按照步骤 就可以导出 json 文件了
我的集群版本是5.0.4不知道能不能行。
另外，是否要导出问题时间的mertics？
是否要导出问题时间的mertics？
–》 是的
我的集群版本是5.0.4不知道能不能行。
–〉 我记忆里 v5 已经可以了(我好像还用过), 可以 grafana --version, 如果满足这个要求就可以
应该还是操作问题
./grafana-server -v
Version 7.5.7 (commit: 91de51771c, branch: HEAD)
这次看起来有数据了
PD_2023-08-11T05_16_51.700Z.json (4.3 MB)
大佬有发现什么问题么。有遇到这个问题了
抱歉, 我只会在某一段时间看 TUG 的帖子, 有时候回消息会出现不及时的情况
现象 :
从 store region score 看, PD 已经识别到 tikv-24 有很高的 score 了, 按理说会往下降低;
但是这个时间段, region score 还在涨, 说明磁盘空间使用在涨, 不像是 PD 的主动行为
region size 很低, 说明这上面的真实数据少(reigon 少), 而且还在进一步减少
region count 很低, 而且还在进一步减少
半个小时时间 磁盘可用空间骤降
分析:
-
v5
egion-score-formula-version应该已经用 v2 了吧, 可以确定下 --》 专栏 - PD 如何调度 Region | TiDB 社区 -
从 v2 的大致公式算(高版本公式有改), 其实无论 v1 还是 v2 其中主要参考的都是磁盘空间
v2 更高版本还会参考写入情况, v5.0.4 应该还没有这个功能 -
从现象上看, 更符合之前老师们的分析, 日志占用或者其他应用有消耗这部分空间
从 metrics 看, 还是有磁盘使用不正常的情况, 可以 diff 一下 正常 tikv 和 这个 tikv 数据目录下各路径下的占用差异, 缩小范围
但是不知道现在是否还能从监控上看到同样的现象, 如果不能, 可以在关键路径上加 crontab du -sh, 到时候再追溯
感谢答疑。
-
参数 region-score-formula-version :region-score-formula-version 参数从 v5.0 版本开始引入，默认值：v2，相比于 4.0 之前 v1 空间回收引起的调度抖动得到改善，整体变化会更平滑。
3.不会有其他应用占用磁盘。
机器上专用的机器，单实例tikv节点独占一台机器。日志清理过tikv日志，还是持续增长。
如果能确定是 tikv 日志的影响原因的话, 估计就要分析下为什么这个 tikv 与其他 tikv 相比打印过多日志了.
是什么日志 tikv.log? rocksdb log? or 其他?
-
最好还是加个 crontab 实锤 log 与磁盘占用之间的关系, 这里有个关键点是 还是持续增长的量有多大
还有之前不均衡的现象是你删完日志就恢复了吗?删的是哪类日志等 - 实锤后再分析, 哪类日志, 为什么产生, 规避 …
基本确定是 日志 的话, workaround 就删吧
如果是不重要日志, crontab 脚本 tick 占用量, 删也行, 就是有点粗暴
收到，我看下
如果某些数据区域特别热点，可能会导致某个节点的磁盘使用率较高。您可以考虑优化查询以减少热点访问，或者通过调整 TiKV 的 region split 策略来分散热点数据。
其余日志清理后，磁盘都是db目录占用
图3的tikv-26、tikv-09 节点的 Oldest snapshots duration非常大；同时磁盘空间占用到达90%
- 正在备份/恢复数据，GC临时关闭。会不会跟GC有关系。
SHOW GLOBAL VARIABLES LIKE ‘%tidb_gc_life_time%’;
gc时间保存多长时间？
在空闲时间对这两个tikv进行一下compact试一下
现在关闭了 set global enable_gc=0;
手动compact会出现磁盘增长么，现在磁盘空间90%了
https://docs.pingcap.com/zh/tidb/stable/tikv-control#手动-compact-单个-tikv-的数据
啥意思，你们关闭了gc？SELECT *FROM mysql.tidb;看一下
| tikv_gc_leader_lease | 20230830-15:42:45 +0800 | Current GC worker leader lease. (DO NOT EDIT) |
| tikv_gc_run_interval | 10m0s | GC run interval, at least 10m, in Go format. |
| tikv_gc_life_time | 8h | All versions within life time will not be collected by GC, at least 10m, in Go format. |
| tikv_gc_last_run_time | 20230829-21:57:45 +0800 | The time when last GC starts. (DO NOT EDIT) |
| tikv_gc_safe_point | 20230829-10:31:45 +0800 | All versions after safe point can be accessed. (DO NOT EDIT) |
| tikv_gc_auto_concurrency | true | Let TiDB pick the concurrency automatically. If set false, tikv_gc_concurrency will be used |
| tikv_gc_scan_lock_mode | legacy | Mode of scanning locks, "physical" or "legacy" |
| tikv_gc_mode | distributed | Mode of GC, "central" or "distributed" |
| tikv_gc_enable | false | |
+--------------------------+---------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+
其他集群也存在这种情况：snapshot 保留很长时间。把磁盘打爆了
不是，为啥关gc啊，你关了磁盘可不占用多吗？
肯定是和GC有关系，GC关闭后，由于TiKV是基于LSM树来实现的，每次数据变更都是只会追加，并不会就地更新/删除。所以TiDB的数据只会增长，永远不会删除，如果数据变化非常快(不管是UPDATE/INSERT/DELETE)，都会导致空间增长很快，一直不能释放
不过你做备份的目的是？5.0还不支持PITR增量备份，如果想做集群迁移，最好是分批拆分迁移，多搭建几个TiCDC来同步。