Closed LinHuiG closed 1 year ago
reset应该少用,所引发的数据安全问题是不可避免的。
主机房全部宕机是小概率事件,主机房有节点异常应该尽快恢复。 另外,可以在主机房部署非投票节点,在不影响协商效率的情况下,尽可能的保证已达成共识的日志复制到其他节点
reset应该少用,所引发的数据安全问题是不可避免的。
主机房全部宕机是小概率事件,主机房有节点异常应该尽快恢复。 另外,可以在主机房部署非投票节点,在不影响协商效率的情况下,尽可能的保证已达成共识的日志复制到其他节点
emmmm,在主机房部署学习者节点与协商效率有什么关系呢,我理解过半复制的效率与学习者并没有直接关系 主机房全部宕机确实是小概率事件,主要是想了解一下在raft在两地三中心的灾备中有没有什么比较好的方案,想下来好像不是很适合。 如果在三地分别部署等量节点的话,也可以防止一个机房都挂掉的情况,但是提交所需的通信延迟代价就会很高。。
或许是我的思路有些问题,可能过度考虑了
那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。
主机房恢复后再重新把节点 addpeer 加进来啊
那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。
主机房恢复后再重新把节点 addpeer 加进来啊
主机房各个节点的已提交日志(1,2,3,4,5,6,7),备机房节点的已提交日志(1,2,3,4,8,9,10),这种情况下addpeer会发生什么呢
那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。
主机房恢复后再重新把节点 addpeer 加进来啊
主机房各个节点的已提交日志(1,2,3,4,5,6,7),备机房节点的已提交日志(1,2,3,4,8,9,10),这种情况下addpeer会发生什么呢
当然以 leader 节点为准啊
那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。
主机房恢复后再重新把节点 addpeer 加进来啊
主机房各个节点的已提交日志(1,2,3,4,5,6,7),备机房节点的已提交日志(1,2,3,4,8,9,10),这种情况下addpeer会发生什么呢
当然以 leader 节点为主啊
哦哦,就直接截断重新同步了对吧
主机房各个节点的已提交日志(1,2,3,4,5,6,7)
这都是你通过 reset 剔除掉的节点了,它上面的日志可视作被你放弃了
那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。
主机房恢复后再重新把节点 addpeer 加进来啊
主机房各个节点的已提交日志(1,2,3,4,5,6,7),备机房节点的已提交日志(1,2,3,4,8,9,10),这种情况下addpeer会发生什么呢
当然以 leader 节点为主啊
哦哦,就直接截断重新同步了对吧
对的
没其他问题就先关闭了
场景:我在两个机房分别部署了raft节点,为了降低提交延迟,我在主机房部署了多数节点,我的问题是:当主机房全军覆没的时候,我可以通过resetPeers强制缩小集群数量让备机房提供服务,那么之后的主机房恢复和切回应该怎么做,直接resetPeers恢复成原来的机器会发生什么。 请问关于可能出现的数据不一致处理有什么比较好的方案吗。比如主机房各个节点的已提交日志(1,2,3,4,5,6,7),备机房节点的已提交日志(1,2,3,4,8,9,10)。 或者关于异地机房的灾备有什么比较好的建议吗。