Data Synchronization

Each standby node automatically synchronizes its data with the data on the active node to ensure that it is constantly ready to take control of the cluster.

The standby nodes perform two types of synchronization:

Remote restore — synchronizes all the data on the standby node with the active node. It occurs the first time a standby node comes online, any time a cluster member comes out of discovery mode as a standby node, and any time the Vocera Control Panel stops and restarts the active node.

A remote restore reads data directly from the database and does not require a backup file.

Note: Stopping and starting the active node does not cause a failover; however, it does cause the standby node to perform a remote restore when the active server restarts.
Ongoing updates — synchronizes the data on the standby node with any changes that occur after the most recent remote restore. The active node records all database transactions that occur after the remote restore starts in a queue, and the standby node uses the queue to update its database.

In addition, a few special files are synchronized outside the remote restore and ongoing updates processes. The following table provides details about how the various types of files used by Vocera are synchronized:

Type of Data	Synchronization Details
The configuration database	Completely updated during remote restore. Kept in sync incrementally during ongoing updates.
Text, voice, and email messages	Completely updated during remote restore. Kept in sync incrementally during ongoing updates.
All user recordings, such as learned names, learned commands, and so forth	Completely updated during remote restore. Kept in sync incrementally during ongoing updates.
Report logs	Existing log files are copied to standby nodes during remote restore. The current log file is copied to standby nodes at one-minute intervals, independently of remote restore. The current log file is copied to the standbys when the voice service closes the file. If a failover occurs, the current log file is never more than one minute old, and all previous log files are already on the standby nodes.
The badge.properties file	Copied to standby nodes during remote restore. Loaded into memory automatically when a standby node becomes active. Best Practice: Modify badge.properties on the active node, and then restart the active node. This action loads badge.properties into memory on the active node and forces the standby nodes to perform a remote restore and synchronize it.
Backup files	Backup files are synchronized outside the remote restore and ongoing updates processes. Standby nodes perform a backup whenever the active node performs a backup. Best Practice: Perform a backup after bringing the cluster online. All nodes will then start with the same backup file.

Several types of files are intentionally not synchronized by the voice service during any process. The following table provides details about the unsynchronized files:

Type of Data	Reason not Synchronized
The properties.txt file	Each Vocera Platform may require hardware-dependent settings in properties.txt. Each Vocera Platform may require different logging parameters in properties.txt.
Vocera Platform logs	Every node creates its own set of server logs. The logs are specific to each node and the state it is in at any given time. Nodes constantly communicate and often log similar events. For example, the logs of both the standby and active node record that the standby node performs a remote restore. Similarly, the logs of both nodes record when a standby node rejoins a cluster after completing a remote restore.
Third-party (Tomcat, Apache, MySQL, and Nuance) logs	Logs provide details for troubleshooting the specific application on the specific server. Processes are not managed by the voice service cluster communication. Files are not relevant from one machine to another.

Type of Data

Reason not Synchronized

The properties.txt file

Each Vocera Platform may require hardware-dependent settings in properties.txt.

Each Vocera Platform may require different logging parameters in properties.txt.

Vocera Platform logs

Every node creates its own set of server logs.

The logs are specific to each node and the state it is in at any given time.

Nodes constantly communicate and often log similar events.

For example, the logs of both the standby and active node record that the standby node performs a remote restore. Similarly, the logs of both nodes record when a standby node rejoins a cluster after completing a remote restore.

Third-party (Tomcat, Apache, MySQL, and Nuance) logs

Logs provide details for troubleshooting the specific application on the specific server.

Processes are not managed by the voice service cluster communication.

Files are not relevant from one machine to another.