Merging Systems in Nx Witness

What Communication Occurs During a System Merge?

When a user initiates a merge between two systems, a primary system is selected which determines which system the system settings, admin user, and cloud users will be saved to before the systems are connected.

The servers open a message bus connection and synchronize their transaction history based on the transaction log of both systems. A transaction is an action executed by the server (e.g. enabling recording on a camera, updating the recording schedule, saving a layout, etc), each of which are saved to a log file.

Transactions are applied one after another according to each transaction's timestamp. Afterwards, all servers in the system constantly synchronize their data across this message bus connection, allowing the client to connect to any server to access the entire system.

Synchronized data between two systems includes the following resources: 

• Servers
• Cameras & Devices
• Users
• Layouts
• Video Walls
• Event Rules

A resource change in one server causes the system-wide database to synchronize that action and be recorded on every server in the system. SQLite journaling is used for the database to ensure safe data dumps.

This process ensures uniformity of recorded data across the entire system and provides the added benefit of fault-tolerance, a single server failure does not lead to system-wide failure.

Nx Cloud System Merge

Nx Cloud merge was introduced in Nx Witness 4.0 and allows systems across different subnets to be merged by establishing communication over an HTTP Proxy tunnel. 

A system merge between Nx Cloud-connected systems makes sure the following prerequisites have been met before initiating the same process as a local merge:

• Systems are on version 4.0 or above, connected to Nx Cloud, and in an online state.
• The Nx Cloud account being used must be the owner of both systems involved in the merge process.

Known Issues

An unexpected issue can occur when merging two systems that both had the same resource at one point. A shared resource creates independent transactions on both servers' transaction logs according to how the resource was managed in each server. Certain changes to the resource that were done on one server but not on the other can cause unintended consequences. 

For example, take the scenario of two systems with the same camera (e.g. CamX): System A and System B. 

1. In System A, an operator enables recording on CamX.
2. Soon after, the operator deletes CamX from System B.
3. The operator merges System A and System B together.

The merge will sync transactions from most recent transactions to oldest. Since the transaction in step 2 occurred after step 1, the camera will be deleted from the merged system before it can process the transaction in step 1.

This behavior will be resolved in future versions, but as a workaround for systems with the same resource, you can attempt the following:

• If not merged yet: Perform a system backup and restore on all servers with the shared resource (this drops potentially unwanted transactions). Afterward, merge as originally intended.
• Unmerge the systems and make sure all resources and settings are correct. Perform a system backup and restore on all servers with the shared resource. Afterward, merge the servers back together.

Questions

If you have any questions related to this topic, or you want to share your experience with other community members or our team, please visit and engage in our support community or reach out to your local reseller.