我理解的场景 tikv1,2,3 用的是挂载磁盘（类似 lvm），tikv4 用的是本地磁盘（不具备扩容条件）
这种场景比较有效的是，对 tikv 1,2,3 进行 lvm 的物理扩容（先让 tikv 4 的数据有地儿放），然后对 tikv4 缩容，缩容后把数据盘挂载到 tikv4 上，最后再 scale-out tikv4 即可
8 天前
我做了下测试，抛开 AZ 可用性，就单机房，我用防火墙隔离了两个 pd 的节点模拟宕机的情况，tikv 均为 down 的状态
[image]
然后最终状态为
[image]
1 个月前
猜测您这边 export 直接用的 tidb 的监控吧，建议自己再部署一个
2 个月前
确认一下哈，看执行计划，你的SQL里面有 join，我理解绑主键做全表 join 应该会慢才对（因为没有走索引），那根据您提问，我感觉是 sql binging 为啥没生效的问题吧？
2 个月前
我的意思是，观察一下拉高负载时，是否会对 region（leader）产生影响，如果有掉地的情况请控制下并发和吞吐
看下副本数是否为 3 (如果您的副本数是 3 副本的话)
region --jq=“.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length < 3)}”
2 个月前
没有更多内容了