sorry ，只是替换了敏感字段，没啥对应关系的

看文档描述貌似不是先判断再执行，而是无脑直接在 tiflash 上 [image]

技术不是越新越好，如果我作为决策者，技术只是我考虑的一方面（大约40%） 简单的说技术的先进性是 yes or no，切换的决策是投入和产出，不是一个维度的

[image] 没 warning，强制 mpp 走的必然是 tiflash

analyze 过，分区健康度 99 ，而且锁定了统计信息，还是走 tikv

https://docs.pingcap.com/zh/tidb/stable/pd-control#operator-check--show--add--remove 参考下这条命令 operator add remove-peer 1 2 // 移除 store 2 上的 Region 1 的一个副本

背景：sysbench 压测过程中，评测 TiDB 8.1.0 的 RU，压测过程根据不同并发进行负载，每个阶段压测 1800s，中间休息 120s 第一阶段(大致)：14:30 ~ 15:00 第二阶段(大致)：15:00 ~ 15:30 第三阶段(大致)：15:30 ~ 16:00 问题描述：第一阶段无法评估 RU 报错如下 ERROR 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; pl…

是root

不行 [image]

重启了下 TiDB，后续就没有复现

没有相关的目录

在 7.5.1 中持续分析如果打开，手动分析是无法打开的，而持续分析关闭后，相应的 profile 没有清理干净，导致手动分析的 cpu 无法执行成功（我对比了下第一次的持续分析中的 cpu 是可以正常分析的），比较尴尬的是这个结果无法通过手动删除 [image]

还有个信息需要补充，我是单机多实例部署的 tikv 还有找了下其他的集群，集群版本是 6.5.9 ，这次是 Heap 报错了 [image]

手动分析， tmp 下没有 [image] [image]

这个和 label 的设置有强耦合，可以把 label 的配置贴一下

我理解的场景 tikv1,2,3 用的是挂载磁盘（类似 lvm），tikv4 用的是本地磁盘（不具备扩容条件） 这种场景比较有效的是，对 tikv 1,2,3 进行 lvm 的物理扩容（先让 tikv 4 的数据有地儿放），然后对 tikv4 缩容，缩容后把数据盘挂载到 tikv4 上，最后再 scale-out tikv4 即可

考虑到成本，暂时混布

如果资源允许可以放 TiFlash

我做了下测试，抛开 AZ 可用性，就单机房，我用防火墙隔离了两个 pd 的节点模拟宕机的情况，tikv 均为 down 的状态 [image] 然后最终状态为 [image]