Startup in an Impact Server cluster

At startup, each server communicates with the Name Server. If no other server is currently registered as primary for the cluster, it registers itself as the primary server. Otherwise, if a primary server is already running, the new server will register as a secondary and copy over artifacts from the primary, so that they are in sync. Artifacts copied include policies, services, data sources and types as well as files, including a zip of the ImpactDB derby database. The impact.file.transfer.timeout property controls how long the new secondary will wait when copying files. You can increase this value if ImpactDB is very large.

If a primary server is already registered, it declares itself a secondary server. By default, each secondary server synchronizes its services, data types, data sources, projects, policies, and configuration settings with the primary server before becoming active.

You can configure the secondary server to wait for the primary for some time. If it does not find the primary in the cluster, after this time, it checks the Name Server if any other server registered itself as primary. If it did not, the secondary server starts itself in primary mode. Otherwise, it registers itself in secondary mode.

Important: In earlier releases, the secondary server did not start, if there were any locked files on the primary. This restriction has been removed in the Netcool®/Impact 6.1.1 release, but you can still choose to keep this restriction, by setting the impact.server.ignorelocksduringreplication property in the server properties file. For more information, see The Impact Server properties file.