版本 v4.0.8
抱歉回复晚了。希望还能帮到您。
https://docs.pingcap.com/zh/tidb/stable/scale-tidb-using-tiup#缩容-tiflash-节点 请参考这个。缩容操作本身会先确保数据被迁移，以达到平滑缩容。
另外如果缩容后节点数小于副本就没办法了，需要先减少副本数到小于集群tilfash节点数。
1 个赞
建议是缩容后维修之后再扩容 恢复原状？有办法不通过缩容扩容的方式，而通过标记查询不走tiflash 标记下线状态再上线的吗？
可以通过设置 tidb_isolation_read_engines 参数让本来走 TiFlash 的查询暂时走 TiKV，然后关闭 TiFlash 进行服务器停机维修，完成之后再次启动并修改设置即可，这样操作起来轻便，不过查询会比较走 TiFlash 变慢。另外环境里是有几个 TiFlash 节点，每个都需要停机维护吗？
目前只启动了一个在测试，考虑到 在数据量比较大的时候 如果是缩容tiflash到再扩容tiflash，销毁副本之后再重建副本，这种情况下对集群TiKV节点的负载是否有较大的影响，对用户查询和更新会有多大的影响？缩容时删除副本用户不可查询tiflash，扩容的同时还用户渐渐恢复tiflash使用？
是否存在这种情况：1.在TiKV上的更新查询压力大了 2.维护时间长 （硬件维修半小时 tiflash维护影响几小时？）
生产环境下，会考虑起两个tiflash节点作为主备，但也有些疑问：如果其中一个需要维修，缩容再重建的情况下，tiflash会从仅存的tiflash中复制还是仍然从tikv行存储复制呢？
第一个问题：建议在停机维护期间设置 engine 先让查询走 KV 上，当然会影响集群的的响应时间，查询压力变大，不过相比较 AP 查询不能用还是比较优的选择。第二个问题：TiFlash 的数据同步都是从 KV 的 region leader 节点来同步数据。
1 个赞
了解 蟹蟹老师
有问题欢迎提问
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。