Replacing a Server in a Merged Environment
-----------------------------------
Related Products: DW Spectrum IPVMS
Last Edit: July 18th, 2024
-----------------------------------
Replacing a Server in a Merged Environment
Database Implementation
A merged system is composed of at least two servers that share users, licenses, configurations, and even cameras in the case of failover. All servers associated with a single merge have a synchronized database, meaning that they all have the exact same database file.
When performing a standard single server replacement, it is advised to apply a database backup to the new server, using a database from the server that is being replaced. The database is expecting to see the original server, which is why the original server populates offline. Since the database is applied to a new server, this is effectively brute forcing a merge. However, in the case of a merged system where one of the servers is being replaced, there is a simpler method to replace the server.
Merge System Replacement Method
As long as at least one server on the merge is functional, you can simply merge the new server into the existing system. Once the new server is merged into the existing system, you can simply click and drag the cameras from the offline/old server and drop them into the resource tree of the new server. Once the new server has all the cameras functional and all necessary licensing has been adjusted, you can simply delete the offline server and create a new database backup that includes the new server.
Can I Use the Standard Method of Server Replacement?
While you still can apply a database backup to the replacement server, the merging method previously explained is preferred. When restoring the database, it will communicate to all the other servers that the database is being restored, causing all the servers to stop and load the database. By merging the new server in (and not applying a database), the other servers on the merge will simply update their database to indicate that there is a new server on the configuration. This is especially beneficial in environments that do not have stable networks or large volumes of servers on the merge, as it will minimize the possibility of failed synchronization of the databases across all the servers.
If you are unfamiliar with merging, you can reference the article on merging here:
- https://support.digital-watchdog.com/kb/article/150-dw-spectrum-merging-and-detaching-servers/
If the old server is not accessible for deactivating licenses, you can submit a manual deactivation form here:
- https://digital-watchdog.com/page/license-deactivation/
If you are replacing a single server that is not part of a merge, refer to the article for single server system replacement:
Additional Notes:
- All the servers need to be on the same version (i.e. 4.2, 5.0, 5.1). If the replacement server is out of date, it will need to be updated. If the replacement server is on a newer version, consider updating the main system’s servers. Otherwise, the replacement server will need to have Spectrum uninstalled, then re-installed with a matching older version.
- If merging via Cloud, all servers need to have the same Cloud Owner. Additionally, if there is a managed network, verify that all cloud services are whitelisted and that there are no web filters preventing communication. (See Firewall Whitelist: https://support.digital-watchdog.com/kb/article/132-dw-spectrum-fqdn-or-allowlist-for-dw-cloud-access/)
- If merging via IP, ensure that the port is accessible (default 7001). If the server is on a remote network, ensure proper port forwarding rules are created on the router/gateway. (See Port Forwarding: https://support.digital-watchdog.com/kb/article/528-port-forwarding-simplified/)
- When selecting the system to take the settings from, ensure that you are selecting the system that has all the settings you wish to keep (usually the original system name).
