Automatic takeover

The role of a node in the Db2® Mirror environment determines whether the replication state transitions to TRACKING or BLOCKED if the nodes can no longer communicate. Ideally, if only one node is available, that node has a replication state of TRACKING so that production work can continue on the node.

If an unplanned outage of the primary node occurs, Db2 Mirror attempts to change the remaining active secondary node to the primary role with a replication state of TRACKING without jeopardizing the integrity of the production data.

When a secondary node loses communication with the primary node, it becomes the primary node and its replication state changes to TRACKING if all of the following are true:
  • Start of changeAutomatic takeover for unplanned outages is enabled.End of change
  • The replication state of the secondary node is ACTIVE and the replication detail is not SYNCHRONIZING.
  • A cluster monitor query for the status of the primary node indicates that the node is not available.

Start of changeIf any of the preceding conditions are not true, the secondary node does not take over as the primary node. The secondary node instead transitions to a replication state of BLOCKED. End of change

Db2 Mirror will not automatically change a secondary node’s state to TRACKING if there is the potential that the unavailable primary node has tracked changes. If one of the above checks fails, here are some reasons that the active secondary node is not allowed to change to TRACKING state.
  • Start of changeAutomatic takeover for unplanned outages is disabled.End of change
  • If the replication state of the secondary node is not ACTIVE or its replication detail is SYNCHRONIZING, there might be tracked changes on the failed primary node that have not been applied. The secondary nodes' replicated objects might not be current. Allowing continued production activity on non-current objects can result in data integrity problems.
  • If the cluster monitor indicates that the primary node is still available, the loss of communication between the nodes might be the result of a network outage. The primary node might still be running in a replication state of TRACKING. The secondary node must remain BLOCKED to protect the integrity of the data.
  • If no cluster monitor is defined on the active node or clustering is not active, Db2 Mirror cannot verify the status of the primary node. It must be assumed that the primary node is available.

If an unplanned outage of the secondary node occurs, the primary node remains unchanged and its replication state changes to TRACKING if previously ACTIVE. Otherwise, the replication state remains unchanged at BLOCKED or TRACKING.

The use of the Power Down System (PWRDWNSYS) command does not result in an automatic takeover since this is considered a planned outage. If the primary node needs to be IPLed, the nodes' roles should be swapped prior to PWRDWNSYS. See Swapping primary and secondary roles for more details on a planned role swap.

If an automatic takeover does not occur, but it is deemed necessary to continue production work on a BLOCKED secondary node, you can force the secondary node to become the primary node running with a TRACKING replication state. This must be done with caution, as it might result in data conflicts between the two nodes when the original primary node becomes available. Corrective action might need to be taken to resolve those conflicts before resuming replication. See Force to TRACKING state for more details.