【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】v7.5.2
【操作系统】centos 7.5
【部署方式】机器部署
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
集群中，有两台物理机，每台机器部署2个tiflash实例。集群中有两张表转储到tiflash，副本数量都是2。其中一台机器半死不活，状态在up和Disconnected来回翻转。
执行缩容操作，摘掉故障机器。期间发现剩余节点的磁盘水位有风险。此时调整tiflash副本数量为1。
想问一下，tiflash减少副本的原理。降低副本数量后，存活的tiflash节点，是从tikv中拉取重新拉取数据，形成一个完成的副本嘛？还是说要从故障节点进行region迁移。
tiflash副本的调整和缩容操作，有先后的区别嘛？
顶起,这个好问题
你当前的核心风险是 “剩余节点磁盘水位有风险”，若先缩容，故障机的 TiFlash 实例被移除后，存活节点需从 TiKV 拉取大量缺失数据，磁盘水位会进一步暴涨，可能导致磁盘满、实例宕机
先调副本数为 1，可让存活节点在 “无缩容压力” 的情况下，逐步从 TiKV 补全数据（或清理冗余副本），待磁盘水位稳定后再缩容故障机，风险更可控
也就是tiflash中的副本数据是从tikv中拉取的，不是从其它tiflash中迁移过来的是不？
也就是降低副本数量和缩容故障节点，没有操作先后的要求是不？
tiflash副本数只会影响AP类查询的快慢和负载，本身不参与数据完整性的仲裁；
一般先降低副本数，再缩容；如果是短时间内先后顺序不影响sql执行（除非tiflash主机本身压力非常大）
也就是说，无论tilfash如何变化，最终是会根据tikv中的数据重建副本数据是不
如果是0到1是从tikv拉，1到2我不确定是不是直接从另一个tiflash副本拉数 
本身tikv和tiflash副本上的数据都是一致的
对，从系统原理理解，应该是这样没错，tiflsh数据是从tikv来的。
我理解tiflash副本数是2，那这两个tiflash节点的数据应该是没有差异的吧。
先调整副本再缩容，tiflash副本本质是TiKV Region 的 Learner 副本，数据来源于TiKV Region Leader
没有差异，如果新加的没同步完成，同步中的副本不可用，只会用到同步完成的那个
就是的，那就先调整副本数
集群中，有两台物理机，每台机器部署2个tiflash实例，这个部署方式有点怪，是两个物理机的物理资源非常充足吗？一般两个物理机，每个部署一个tiflash实例就好了。。。
TiFlash 副本属于 TiDB 集群的列存副本 ，PD 会根据表的 tiflash_replica 配置（即副本数），为表的每个 Region 维护指定数量的 TiFlash 副本。当将副本数从 2 降为 1 时，PD 会触发副本淘汰 逻辑，对每个 Region 只保留一个有效 TiFlash 副本，其余副本标记为 “待清理”。