一年前3季度dmr 最后一个季度lts DMR 可以用小版本号， 版本号别推的那么高，后面念着都绕口了

[image] 这压力有点大了， 看描述这当时引入这算法就是为了降低迁移时的影响 [image]

不一样磁盘大小的 我会调整region_weight [image]

[image] 你df看下磁盘空间是多少

试试把leader-schedule-limit 调到一个很小的值 比如1 ,减少这类调度和balacne region的争抢，但有可能会导致tikv cpu利用率不均衡

看下pd监控的operator产生和消费正常吗。正常的话先试试调大调度参数 pd-ctl config set 调整 replica-schedule-limit ，max-pending-peer-count 以及 max-snapshot-count 。 pd-ctl store limit all xx 增大store limt。

还是得看日志啊，找个region 看看pd leader 和 tikv.log 有啥报错导致调度下发了，但是执行不成功

tiup cluster display 看下集群状态

单副本肯定是因为你就一个tikv ， 也很好奇为啥你没调整max-replicas 单副本也能跑起来。 理论上你副本数是设置3 ，是会补副本的。

operator add add-peer 2 5：在 Store 5 上为 Region 2 添加 Peer 用pd-ctl 试试手工再其他节点添加副本能不能成功

如果其他节点一直副本没补成功，看看日志里能不能看到些信息。

看这个日志， 他在往另一台上去添加副本，你按这个region id 搜下tikv.log 和pd leader的log 看看有没有啥报错信息， 还有就是你说的缩容报错，看你发的日志 这一个正常的Info信息，你说的报错是什么样。你注意观察下store_id=1上的region count是不是再减少 其他上的再增加，我感觉这个上的region 得要先补完副本 才能处理下线的操作。 region_count 可以从 tikv_store_status里直接查 或者 直接看监控 overview-> tikv 里的region/leader监控

pd-ctl config show 看看

还有就是 你那4个tikv的磁盘剩余空间是否充足？

你说的1个节点 只有1副本，其他的是3副本这个怎么确定的。 你看下你说的1副本的找个region id 然后pd-ctl region xxx 看看具体的信息

[image] 你就这3台主机吗？ 在100上先扩一个tikv

select store_id,address,label from information_schema.tikv_store_status

你的每个 tikv label怎么配置的？

https://github.com/pingcap/tidb/pull/8021 确实有这种消除优化 ，不过看时间是2018年