1. #fabric-orderer
  2. Verify if the newly added orderer node has synced the blocks in Hyperledger Fabric

Verify if the newly added orderer node has synced the blocks in Hyperledger Fabric #hyperledger-fabric #raft #fabric-orderer

chintanr97@...
 

I am adding a new orderer node by following the steps mentioned here: Reconfiguring the RAFT cluster.
 
In the 5th step we can see that following is mentioned:
 
Waiting for the Raft node to replicate the blocks from existing nodes for all channels its certificates have been added to. After this step has been completed, the node begins servicing the channel.
 
Now, I went through a few options to perform this step.
 
  1. Manually check the new orderer node logs.
  2. For automation purposes, we can see the orderer metrics. Of this, I feel consensus_etcdraft_committed_block_number is a good choice. We can fetch the given metric value from existing orderer and wait for the new node to reach at that block number. The issue arises when the network is dynamic. Meaning, for the time that the new node syncs old blocks, there might have been new updates to the channel in that duration.
So, my questions are:
 
  1. Should we wait for the new orderer node to sync those blocks as well which were committed in the ledger in the gap period of it being in sync with others?
  2. If yes, then we would have to keep fetching above metric value from an existing orderer and the new orderer until both of them reach at a sync stage (which I feel is too much overhead for production use). So, is there a better approach or an orderer metric which I might be missing, which could help us here?
1 - 1 of 1