问题描述
我最近使用Docker-compose部署了Fabric网络,当时我试图模拟一个崩溃的对等节点.本质上就是这样:
I recently deployed the fabric network using Docker-compose, I was trying to simulate a downed peer. Essentially this is what happens:
- 使用运行构架网络的docker-compose使4个对等节点联机
- 1个对等体,即第4个对等体发生故障(通过docker stop命令完成)
- 将调用事务发送到根对等方,然后在一段时间后通过查询对等方(不包括被关闭的对等方)来进行验证.
- 被打倒的同级设备通过docker start进行备份.查询事务在始终连接的对等节点上运行良好,但在新唤醒的对等节点上失败.
一旦第四个对等点启动后,为什么它不同步区块链,是否需要采取步骤来确保它呢?还是将其作为流氓同伴而丢弃.
Why isn't the 4th peer synchronizing the blockchain, once its up.Is there a step to be taken to ensure it does? Or is it discarded as a rogue peer.
推荐答案
这可能是由于PBFT的预期行为(假设您正在使用它).如问题933 所述,
This might be due to the expected behavior of PBFT (assuming you are using it). As explained on issue 933,
如果关闭另一个同伴,则应注意您最初关闭并重新启动的那个现在充分参与,网络将继续取得进展.作为只要网络在进步,参与的节点共享正确的前缀,一切都很好. f个副本的原因落后的是那些f可能正在扮演拜占庭式的进步故意慢慢地.您无法分辨出速度较慢的区别正确的副本,以及故意较慢的拜占庭副本.因此,我们不能等待最后的f散客.他们将被留下落后并偶尔同步.如果事实证明还有其他副本已崩溃,网络将停止进度,直到一个正确的流浪者赶上了,然后网络将前进通常.
If you shut down another peer, you should observethat the one you originally shut off and restarted will nowparticipate fully, and the network will continue to make progress. Aslong as the network is making progress, and the participating nodesshare a correct prefix, you're all good. The reason for f replicaslagging behind is that those f may be acting byzantine and progressdeliberately slowly. You cannot tell a difference between a slowercorrect replica, and a deliberately slower byzantine replica.Therefore we cannot wait for the last f stragglers. They will be leftbehind and sync up occasionally. If it turns out that some otherreplica is crashed, the network will stop making progress until onecorrect straggler catches up, and then the network will progressnormally.
这篇关于光纤网络-发生故障的对等方重新连接到网络时会发生什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!