This chapter provides an overview about how IBM Db2 Mirror for i provides continuous availability for different planned and unplanned outages.

For a planned outage scenario such as performing hardware, operating system (OS), or application maintenance on the Db2 Mirror secondary node, Db2 Mirror replication can be suspended, which causes the primary node to track changes and the secondary node to block changes (if the planned maintenance affects the primary node, a Db2 Mirror role swap can be performed). After the planned maintenance on the secondary node, Db2 Mirror can start synchronization again between both nodes.

This maintenance approach can also be used as follows for a rolling update scenario like planned program temporary fix (PTF) installations on both nodes:

If the Db2 Mirror pair is used in an active-active operation model, the user might want to ensure that, either by an active-active application design that provides automated workload failover or by manual actions, the workload is repositioned from the secondary node to the primary node before proceeding with suspending Db2 Mirror in step 2.

If the Db2 Mirror pair is used in an active-passive operation model, the user might want to end their reporting or analysis-based type of workload on the secondary node before proceeding with suspending Db2 Mirror in step 2. The reasoning is that even though reads continue to succeed after the secondary node reaches the suspended/blocked state, the data might not reflect the state of the business.

Another option to prepare a Db2 Mirror pair for planned maintenance, especially hardware maintenance or server migration, without having to tolerate a longer duration of suspended Db2 Mirror replication is to use PowerVM Live Partition Mobility (LPM) for migrating a Db2 Mirror node to another IBM Power Systems server. For more information about the requirements for using LPM with Db2 Mirror, see 1.4.5, “Db2 Mirror and Live Partition Mobility” on page 14.

The procedure to use for live migration of either the primary or secondary Db2 Mirror node is as follows:

Suspending Db2 Mirror for planned maintenance can be accomplished as shown in Figure 5-1. Right-clicking a node from the Db2 Mirror GUI home page and select Suspend Db2 Mirror to stop replication.

Alternatively, you can suspend Db2 Mirror replication by using the Db2 Mirror SQL services procedure CHANGE_MIRROR, as shown in Example 5-1. The SUSPEND action requires *SYSBAS as the IASP_NAME and suspends both SYSBAS and any database IASP (DB IASP) replication.

After the planned maintenance is complete, you can resume the suspended Db2 Mirror replication from the Db2 Mirror GUI home page by right-clicking a node and selecting Resume Db2 Mirror, as shown in Figure 5-2.

Alternatively, you can resume a suspended Db2 Mirror pair by using the SQL services procedure CHANGE_MIRROR, as shown in Example 5-2.

After Db2 Mirror resumes, data resynchronization starts between the primary and secondary nodes, as shown in Figure 5-3, until both nodes are in the active-replicating state again.

This section provides a brief overview about how unplanned outages are handled by Db2 Mirror, and which recovery actions are possibly required by the user.

If the Db2 Mirror secondary node becomes unavailable (for example, an IPL occurs, it goes into a restricted state, or there is a main storage dump as illustrated by Figure 5-4), the Db2 Mirror primary node begins tracking replicated object changes, as shown in Figure 5-5, and user applications (if all their dependent data was included in Db2 Mirror replication before) continue to run.

After the secondary node becomes available again, it is in a blocked state, as shown in Figure 5-6, and it does not allow changes to replicated objects until the two nodes resume mirroring. Db2 Mirror by default automatically resumes mirroring after the secondary node becomes available again.

This section describes the scenario of a primary node outage in a Db2 Mirror environment, as shown in Figure 5-7.

The handling of a primary node outage by Db2 Mirror depends on the condition that led to the primary node not being available. These conditions are described in the following sections.

The secondary node remains blocked and the primary node tracks while it is in a restricted state or until the IPL completes. An IFS IASP is failed over by PowerHA to the secondary node if it is not prevented by a user-defined PowerHA policy and the cluster resource group (CRG) has not ended before. Figure 5-8 shows the states of the nodes and the IASP for this scenario.

The user can then still decide whether they want to wait for the primary node to become available again. If they prefer to continue working with their database applications, they may perform a Db2 Mirror role swap, as shown in Figure 5-9.

The role swap forces the blocked secondary node to become a suspended and tracking primary node. Db2 Mirror requests the user to confirm this action, as shown in Figure 5-10. The block secondary node has the potential for object collisions because some changes, such as security-related objects as user profiles and authorization lists or for system values, are allowed in the blocked state.

After the role swap, the blocked secondary node becomes a tracking primary node, as shown in Figure 5-11. (The Db2 Mirror GUI shows the primary node always on the left of the window.)

If the secondary Db2 Mirror node can connect to the Hardware Management Console (HMC) and determine that the primary node failed, the secondary node takes over as the primary and begins tracking.

Otherwise, if the secondary cannot detect the failure, it remains blocked, as shown in Figure 5-12.

If the user does not want to wait for the primary to become available again to continue to work with their database applications, they may perform a Db2 Mirror node role swap to force the secondary to become the primary, as described in “Primary node becomes unavailable due to an IPL or going into a restricted state” on page 76.

If communication is lost between the two Db2 Mirror nodes over the RoCE network, as illustrated by Figure 5-13, the primary tracks replicated objects, and the secondary blocks changes to replicated objects, as shown in Figure 5-14 on page 79, until mirroring can resume. Db2 Mirror by default automatically resumes its mirroring after the communication between the two nodes is reestablished.