You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi!
We are trying to use dragonboat and we have usecase when node is being removed from the cluster, cleared and after some time plugged back to the cluster. Dragonboat states that "Requesting a removed node back to the Raft cluster will always be rejected.", however we wanted to map our own unique entity one to one to nodeID. In this case it would still be the same and nodeID addition will be rejected.
Can you please explain what is the reason for this limitation in case we start a fresh node with the same ID?
Thanks in advance
The text was updated successfully, but these errors were encountered:
Seems to me like disallowing the reuse of node IDs just simplifies the protocol and implementation by not having to keep track of extra metadata. If you did want to support node ID reuse, you would have to keep track of a sort of node generation ID in order to allow a node to correctly transition from a closed state to an open state.
This maybe makes more sense in v4 terminology where nodes are called replicas. If you remove a replica from the shard and try to add it back, you have to pull a fresh snapshot and are thus creating a new replica which is a standard procedure. Best to just march forward with your replica IDs and not try to assign them any special meaning.
Hi!
We are trying to use dragonboat and we have usecase when node is being removed from the cluster, cleared and after some time plugged back to the cluster. Dragonboat states that "Requesting a removed node back to the Raft cluster will always be rejected.", however we wanted to map our own unique entity one to one to nodeID. In this case it would still be the same and nodeID addition will be rejected.
Can you please explain what is the reason for this limitation in case we start a fresh node with the same ID?
Thanks in advance
The text was updated successfully, but these errors were encountered: