Listener failover scenario 2: Master listener node fails

This topic pertains to a clustered listener configuration. In this scenario, the master listener node is unresponsive. Either the node is down or is not reachable due to network issues.

The node is determined to be unresponsive based on a limited number of retries within a certain time period.

In this case, the Unica Campaign web application asks the next node in the cluster to become the master listener, based on masterListenerPriority. The node becomes the master listener based on master listener election and takes over load balancing duties. The master listener also performs session synchronization between multiple listeners.

When the unresponsive node comes back up, it performs as a non-master listener. It does not automatically regain master listener status. If you want to make a different listener the master listener, you must stop the currently serving master listener first.

The cluster configuration changes are recorded in the masterlistener.log.

Note: If a user was editing a flowchart or other object, any unsaved data is lost. The cluster automatically re-establishes the connection to the same session file (.ses) for the flowchart in Edit mode. However, any data that was not saved (either manually or by configured checkpointFrequency and autosaveFrequency) is lost.