【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1.0
【复现路径】未做过复现
【遇到的问题：问题现象及影响】
需要快速缩容TiFlash（20min内），tiflash大概同步100亿行数据，如何选呢？
方案1:
https://docs.pingcap.com/zh/tidb/v8.3/scale-tidb-using-tiup#方案一通过-tiup-缩容-tiflash-节点
方案2:
https://docs.pingcap.com/zh/tidb/v8.3/scale-tidb-using-tiup#方案二手动缩容-tiflash-节点
现在有122K个leaner
我有另外一个方式，修改 tidb_isolation_read_engines，把 tiflash 移除掉，那么理论上 SQL 就不会用 tiflash 了，然后再 scale-in
了解。按您的方法来讲能快速scale-in tiflash么。
我这边整体计划是：
先scale-in AZ1的tiflash
再scale-out AZ2的tiflash
那我理解的不对了，我以为咱们的最终目的是“不用 tiflash”。但目前看咱们的目的只是“快速缩容 tiflash”
是的，快速缩容。
之前想到，担心时效太慢（节点状态变为Tombstone太慢）：
1、缩所有表副本=0
2、scale-in tiflash
3、scale-in tiflash --force
没试过这个 https://docs.pingcap.com/zh/tidb/v7.1/tikv-control#设置一个-region-副本为-tombstone-状态
如果是正常的下线，最慢的就是迁移leader和清理region吧
https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#节点下线速度慢
问题解决了吗，分享一下经验？
嗯，可能是数据量少？
如果你的目的是把tiflash从az1迁往az2，我觉得应该先扩容，再缩容。
特别是开了mpp模式的情况下，因为mpp模式下所有tiflash节点都参与计算，如果先缩容，可能导致mpp的效率短期下滑，造成很多慢查询。影响系统稳定。
先扩容再缩容就好一些。
如果彻底不用tiflash的角度，我觉得 @MrSylar 的方案更好。
