使用jraft进行多地灾备的问题

[LinHuiG]

场景：我在两个机房分别部署了raft节点，为了降低提交延迟，我在主机房部署了多数节点，我的问题是：当主机房全军覆没的时候，我可以通过resetPeers强制缩小集群数量让备机房提供服务，那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。 请问关于可能出现的数据不一致处理有什么比较好的方案吗。比如主机房各个节点的已提交日志（1,2,3,4,5,6,7），备机房节点的已提交日志（1,2,3,4,8,9,10）。 或者关于异地机房的灾备有什么比较好的建议吗。

[shihuili1218]

reset应该少用，所引发的数据安全问题是不可避免的。

主机房全部宕机是小概率事件，主机房有节点异常应该尽快恢复。 另外，可以在主机房部署非投票节点，在不影响协商效率的情况下，尽可能的保证已达成共识的日志复制到其他节点

[LinHuiG]

reset应该少用，所引发的数据安全问题是不可避免的。

主机房全部宕机是小概率事件，主机房有节点异常应该尽快恢复。 另外，可以在主机房部署非投票节点，在不影响协商效率的情况下，尽可能的保证已达成共识的日志复制到其他节点

emmmm，在主机房部署学习者节点与协商效率有什么关系呢，我理解过半复制的效率与学习者并没有直接关系 主机房全部宕机确实是小概率事件，主要是想了解一下在raft在两地三中心的灾备中有没有什么比较好的方案，想下来好像不是很适合。 如果在三地分别部署等量节点的话，也可以防止一个机房都挂掉的情况，但是提交所需的通信延迟代价就会很高。。

[LinHuiG]

或许是我的思路有些问题，可能过度考虑了

[fengjiachun]

那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。

主机房恢复后再重新把节点 addpeer 加进来啊

[LinHuiG]

那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。

主机房恢复后再重新把节点 addpeer 加进来啊

主机房各个节点的已提交日志（1,2,3,4,5,6,7），备机房节点的已提交日志（1,2,3,4,8,9,10），这种情况下addpeer会发生什么呢

[fengjiachun]

那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。

主机房恢复后再重新把节点 addpeer 加进来啊

主机房各个节点的已提交日志（1,2,3,4,5,6,7），备机房节点的已提交日志（1,2,3,4,8,9,10），这种情况下addpeer会发生什么呢

当然以 leader 节点为准啊

[LinHuiG]

那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。

主机房恢复后再重新把节点 addpeer 加进来啊

主机房各个节点的已提交日志（1,2,3,4,5,6,7），备机房节点的已提交日志（1,2,3,4,8,9,10），这种情况下addpeer会发生什么呢

当然以 leader 节点为主啊

哦哦，就直接截断重新同步了对吧

[fengjiachun]

主机房各个节点的已提交日志（1,2,3,4,5,6,7）

这都是你通过 reset 剔除掉的节点了，它上面的日志可视作被你放弃了

[fengjiachun]

那么之后的主机房恢复和切回应该怎么做，直接resetPeers恢复成原来的机器会发生什么。

主机房恢复后再重新把节点 addpeer 加进来啊

主机房各个节点的已提交日志（1,2,3,4,5,6,7），备机房节点的已提交日志（1,2,3,4,8,9,10），这种情况下addpeer会发生什么呢

当然以 leader 节点为主啊

哦哦，就直接截断重新同步了对吧

对的

[fengjiachun]

没其他问题就先关闭了