感觉tiflash处理olap有优势，但是处理修改数据上还是需要改进
感谢 zhenjiaogao和 h5n1的支持。
目前根据官方指导初步判定是以前曾经有过force缩容导致一个region leader缺失所致，查看tidb日志可以发现gc相关的问题，后继解决之后我再来同步处理办法。
1 个赞
:+1 原理和处理思路 超清晰
近期有一些重要事务未来的及处理上述问题，今天上午操作了一下记录如下。
1.确定集群的无leader region个数
python3 tk_pdctl.py -u pd-ip:2379 -o showRegionsNoLeader
发现只有1个无leader region，其包含4个peer：[9,3163837,8,3163836]，查了下目前只有9还活着，剩下3个store已经不存在于集群中了。
2.暂停pd调度(注释为原值，方便修复后回退)：
config set leader-schedule-limit 0 //4
config set region-schedule-limit 0 //4
config set replica-schedule-limit 0 //8
config set merge-schedule-limit 0 //8
config set hot-region-schedule-limit 0 //4
3.先停掉store_id为9的这个store: tiup cluster stop <cluster-name> -N <store_node_id>
4.拷贝集群对应版本的tikv-ctl到store_id=9的节点,并执行恢复：
$ scp /home/tidb/.tiup/components/ctl/v4.0.16/tikv-ctl <ip>:/home/tidb
$ ./tikv-ctl --db /data/tikv20171/data/db unsafe-recover remove-fail-stores -s 3163837,8,3163836 -r 70428053
removing stores [3163837, 8, 3163836] from configurations...
success
大概耗时十多秒的样子
5.重新启动store_id=9并恢复pd调度配置
tiup cluster start <cluster-name> -N <store_node_id>
// 恢复pd调度值的语句这里不重复贴了
6.查看故障region的状况
python3 tk_pdctl.py -u 10.16.135.111:2379 -o showRegion -r 70428053
// 发现leader转移到了9，但是还没有其他peer，估计还没开始调度，等不及了于是自己加peer
// pdctl操作(选了2个其他host上的store)：
operator add add-peer 70428053 5
operator add add-peer 70428053 76333554
// 然后再次查看region70428053变为正常的3副本。
7.验证gc的恢复：
查看日志暂时没发现什么有用信息，但下一次gc开启后mysql.gc_delete_range_done的记录开始迅速增长，集群数据量开始减少。
重要补充：
忘了说，由于本集群gc任务暂停过久，所以官方人员提示gc重启后集群压力可能陡增，因此提前调整了gc流控和tikv compaction相关参数，具体修改的值如下：
// 针对所有tikv实例执行以下操作：
tikv-ctl --host=${storeIP}:${port} modify-tikv-config -n rocksdb.writecf.soft-pending-compaction-bytes-limit -v 256GB
tikv-ctl --host=${storeIP}:${port} modify-tikv-config -n rocksdb.writecf.hard-pending-compaction-bytes-limit -v 512GB
tikv-ctl --host=${storeIP}:${port} modify-tikv-config -n rocksdb.defaultcf.soft-pending-compaction-bytes-limit -v 256GB
tikv-ctl --host=${storeIP}:${port} modify-tikv-config -n rocksdb.defaultcf.hard-pending-compaction-bytes-limit -v 512GB
tikv-ctl --host=${storeIP}:${port} modify-tikv-config -n gc.max-write-bytes-per-sec -v 20MB
可以将上面过程单独写个 技术文章帖子，另外缩容时为何导致leader缺失有说法没
嗯。
相关的tidb日志已经在磁盘空间告警时时自动清掉了，只能从tiup audit看到一些force scale-in的记录，去年11.04号有一台机器宕机(gc_delete_range_done的截止日期是2021-11-04 02:36:49)，于是当天下午正常scale-in，11.08号可能是发现4天过去了一直没变tombstone强制scale-in了。
问题大略就是替换故障机器时遗留一些region未能正常转移走，关于此类场景我之前也发过2个帖子，都是12月之后的事了，当时应该没意识到应该观察下region是否清0。
我也遇到这个问题了，force scale in，truncate空间不回收。我试试楼主的方法
补充另一种GC推进会被阻塞的场景…今天遇到了：
一个集群早期部署了cdc到kafka的同步，后来不用了cdc组件也没怎么管，今天突然发现实际数据量应该只有十几GB磁盘空间却占了几个TB。
看了下是gc safe point不再推进了，tidb的gc日志显示一直有个gc进程跑着阻塞新开的gc进程。
找了一会儿发现是cdc里边有个change feed的checkpoint停在了很久之前，删掉废弃的cdc组件可恢复。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。