Synchronization

The synchronization in a multi-node site is two-way:

• The central node requests updates from the rim nodes every 15 seconds.
• Each rim node initiates a synchronization session with the central node every 15 seconds.

When changes are made on each node, the resulting transactions are recorded in a transaction log. During the synchronization, the latest set of transactions from the log is sent to the other nodes and replayed.

The synchronization is not visible to the users, who can continue to work in their apps while new data is synchronized in the background.

Data to synchronize

There are two types of data that need to be synchronized:

• Entity data: The repository database contains the system configuration and all meta data about apps. This data is referred to as entity data and is usually small in size. The repository database is controlled by the Qlik Sense Repository Service (QRS).
• Binary data: The app data files contain the data models and app definitions. These files are referred to as binary data and the data model element of the files can be large in size. The app data files are controlled by the Qlik Sense Engine Service (QES).

Entity data synchronization

If the transaction log only contains entity data (that is, changes in the repository database), an entity data synchronization is performed. The changes are applied immediately in the repository database on the receiving node. If a conflict occurs, the latest transaction is used.

Example:  

A user consumes a license on a rim node. The record is committed to the repository database and a transaction is recorded in the log. During the next synchronization, the central node asks the rim node for its latest transactions and applies them to its local database. The rest of the rim nodes get the same update from the central node during their next synchronization.

Binary data synchronization

If the transaction log contains binary data (that is, changes to app data files), a binary data synchronization, during which the receiving node obtains the updated data, is initiated. The entire app data file does not have to be copied, just the components that have changed. This means that small edits (for example, a new sheet in an app) are synchronized quickly and independently from a large edits (for example, a data model that is synchronized after a reload). During binary data synchronization, the nodes use peer-to-peer replication to speed up the synchronization of large apps and prevent network bottlenecks.

Example:  

An app is reloaded on a rim node. During the next synchronization, the central node checks the transaction log and initiates a binary data synchronization. The rest of the rim nodes get the same update during their next synchronization with the central node. However, the rim nodes can obtain the binary data not just from the central node, but from any rim node that already has the updates.