|About Vocera Voice Server Clusters / Network Problems and Clustering|
If your network has an outage or experiences extreme latency during a remote restore, this synchronization operation may fail.
As described in Synchronizing Extensive Changes, the remote restore operation itself is fairly efficient, and it is unlikely to be the cause of such latency.
When a remote restore fails, the standby node automatically attempts to reconnect to the active node and perform the operation again. If the outage or latency was momentary, a retry is usually sufficient to allow the remote restore to complete.
If necessary, the standby node attempts to perform a remote restore a total of three times. If the remote restore fails three successive times, the standby node stops retrying and displays the following error message: “Restore from active server failed.”
After you close this dialog box, the standby server becomes a standalone Vocera Voice Server, and the cluster is in a split brain state. This standalone server has an empty database, and its split brain state is more benign than the one described in Network Problems and Clustering for the following reasons:
Badge users are not affected.
The active node remains in control of the cluster.
The standalone server halts, preventing badges from connecting to it.
Make sure you understand and solve the network problem that caused the cluster to enter this state before starting the standalone server and attempting to rebuild the cluster. Do not start the standalone server without joining it to the cluster again, because badges that were off network when the failure occurred may return and connect to it.
To rejoin the cluster if remote restore fails three times: