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
In order to reach a highly available metadata store when starting with a single metadata store peer after provisioning, we need to be able to add more peers to the metadata store cluster. While at it, we should also add an option to remove a peer. How the exact procedure looks like will depend on the chosen consensus protocol.
OmniPaxos requires us to propose a new configuration. Once the new configuration has been applied, we need to make sure that newly added nodes are started with the latest kv-store state. This will probably entail that a previous node creates a snapshot which can be fetched by the new node.
Raft requires us to propose a new configuration. As part of the configuration change, new nodes will fetch the up to date log from the existing peers. Therefore, there is no need to manually transfer the kv-store state to a new peer.
Independent of the actual procedure, we need to make sure that reconfigurations survive node crashes. E.g. when using the OmniPaxos protocol the reconfiguration procedure looks like a multi step process. We must ensure that we can recover at any point in time in case of a crash/failure.
The text was updated successfully, but these errors were encountered:
In order to reach a highly available metadata store when starting with a single metadata store peer after provisioning, we need to be able to add more peers to the metadata store cluster. While at it, we should also add an option to remove a peer. How the exact procedure looks like will depend on the chosen consensus protocol.
OmniPaxos requires us to propose a new configuration. Once the new configuration has been applied, we need to make sure that newly added nodes are started with the latest kv-store state. This will probably entail that a previous node creates a snapshot which can be fetched by the new node.
Raft requires us to propose a new configuration. As part of the configuration change, new nodes will fetch the up to date log from the existing peers. Therefore, there is no need to manually transfer the kv-store state to a new peer.
Independent of the actual procedure, we need to make sure that reconfigurations survive node crashes. E.g. when using the OmniPaxos protocol the reconfiguration procedure looks like a multi step process. We must ensure that we can recover at any point in time in case of a crash/failure.
The text was updated successfully, but these errors were encountered: