马克围观下

申请测一下呢？ 这样也能产出成本投入情况（这个在选架构时候，通常比较重要）。

了解，get。谢谢

明白，您有办法复现么，我想小版本7.1.0 → 7.1.6，担心引入更大故障。

比如：集群开启cdc后，drop1张表，但region没GC；其他表又复用这个region，随着表数据写入，region split了。这就会导致 tikv 挂了。 或者两个小表共用一个region，随着数据增长region split？

请问，v7.1.7什么时候发布，另这个问题是哪些场景稳定触发。

get！！ 我是通过关闭gc.compactioin 的，不太清楚打开有啥问题，snapshort正常推进，数据不gc。

是的，看磁盘持续没释放，就改了gc参数。现在释放了

收到，其它集群我按照这个搞。 集群没有tiflash。

确实有load base split duration 监控分布多了一些。 [image]

嗯呢，多谢，我再等等。

有可能，也好几个小时了，按理应该可以删一些。 下面是尝试resole-lock，是有事务卡住了？tso解析时间跟gc-life-time时间一致 ` [gc worker] finish resolve locks"] [uuid=651272028540017] [safePoint=459810137488752640] [try-resolve-locks-ts=459810137488752640] [regions=339672] tso 459810137488752640 system: 2025-08-01 16:21:14.185 +0800 CST logic…

删除脚本逻辑是：根据主键ID递增删除，发现有比较多remove-hot，transfer-hot-write-leader的调度线程（时间能吻合上）。 会不会是主键递增删除，会使更多线程用在调度hot region，导致check、merge region慢？ [image]

62节点启动多长时间了； 另到 /data/tikv-20160目录，看下文件有哪些。

还能兑换课程，马克，空了试一下，纯纯福利。

搞定后做个定期备份到异地机房吧。 https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-meta-backup/#tiup-cluster-meta-backup 或者 https://docs.pingcap.com/zh/tidb/stable/tiup-cluster/#迁移中控机与备份

【你看过哪些让你眼前一亮的架构案例或设计思路？】 aws 的aurora 架构，存算分离，不用考虑数据存储；闪存快照等特性 【所在行业的场景对系统架构有哪些要求？】 高可用，稳定 【你认为 TiDB 是否能让您现有的架构在满足业务需求的同时更加简洁、高效和优化？】 基本满足，bi小伙伴反馈能用。

收到大佬宝贵经验

借楼问一下，怎么处理的呢。