replace-down-replica与replace-offline-replica的区别

[furyamber]

我们现在在测试环境执行了scale-in --force
此时查看779940的store状态是offline
然后用curl -XPOST “http://192.168.0.218:2379/pd/api/v1/store/779940/state?state=Up”
这样的命令发现，779940这个这个状态变成了disconnect,30分钟后变成了down

按照之前看pd日志，我们发现replace-offline-replica跟replace-down-replica的处理逻辑是不一样的。
此时有没有可能如果2个非正常下线的都用curl变成了down状态，
有没有可能会通过replace-down-replica补足三个副本

[zhenjiaogao]

@zhenjiaogao

当然，如果你那里下线的 2 个 store 仍然是 offline 状态，并且服务器和数据目录均在，那么可以使用下面的命令先把节点的状态修改为 UP，终止 store 的下线操作，避免 2 副本丢失的问题。建议在测试环境验证下:

curl -X POST http://${pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Up

上面说了，这个命令适用的范围是数据目录和目标服务器仍然存在，你用了 --force，那么数据目录是删除的状态，所以，这个命令不适用

@furyamber

此时有没有可能如果2个非正常下线的都用curl变成了down状态，
有没有可能会通过replace-down-replica补足三个副本

如果非正常下线的 store 变成了 down，并且没有出现大多数副本丢失的情况，那么是可以通过 pd 调度来补充丢失的 1 副本。当前的产品形态是，一旦出现的 region 多副本丢失，不论是怎样的原因造成的，都无法通过 pd 调度自动补齐，需要使用 unsafe 命令修复仅存活的 peer