Best practices for system management
To avoid production outages, one of the two Db2® Mirror nodes must be available at all times. The available node needs to be designated as the primary node to allow changes to replicated objects. Before a planned outage of a primary node, perform a role swap to make it the secondary node.
Before system maintenance is performed, if you are running active workloads on both nodes, prepare the node that will remain available to accept the extra work. An example would be to add more prestart jobs for production activity on the node that will remain active.
Planned outages
For planned outages, Db2 Mirror does not perform an automatic role swap by default. Planned outages include the End TCP/IP (ENDTCP), End Subsystem (*ENDSBS *ALL), Power Down System (PWRDWNSYS), or End System (ENDSYS) commands. If the primary node experiences a planned outage, the secondary node suspends replication and changes to a BLOCKED replication state. A replication state of BLOCKED means that no updates to replicated objects are allowed. Before a planned outage of the primary node, perform a role swap so the remaining node changes to a replication state of TRACKING so production work can continue on the remaining node.
To change the default behavior for End Subsystem (*ENDSBS *ALL), Power Down System (PWRDWNSYS), and End System (ENDSYS), the automatic role swap property can be changed to Yes. This property can be changed by using the Db2 Mirror GUI or the QSYS2.CHANGE_MIRROR procedure. For more information about the automatic role swap property, see Db2 Mirror properties.
An alternative approach to implementing an automatic role swap for a command such as PWRDWNSYS is to use a command exit point to initiate a role swap.
Takeover IP address groups are not swapped automatically as part of a planned outage. Before a planned outage, consider swapping your takeover IP address groups to the node that will remain active. For more information, see Managing takeover IP address groups.
- An option to swap the current active node of all IP takeover groups to the new primary node.
- An option to switch the preferred node for all takeover IP address groups.
When SQL services are used to swap roles, use the QSYS2.SWAP_MIRROR_TAKEOVER_GROUP procedure to swap takeover IP address groups. The QSYS2.CHANGE_MIRROR_TAKEOVER_GROUP procedure can be used to change the preferred node.
Installing PTFs
Individual PTFs, cumulative PTF packages, and PTF groups can be installed on one node at a time. Replication can be suspended and the PTFs can be installed on the secondary node. After replication is resumed, a role swap can be performed. Then, replication can be suspended and the PTFs installed on the other node, now the secondary.
- Most Db2 Mirror PTFs can be applied by using the normal suspend process on one node at a time.
- Some Db2 Mirror PTFs might require suspending for maintenance for the PTF to be activated.
For more information about PTF groups for Db2 Mirror, see PTFs for Db2 Mirror.
Upgrading the IBM i operating system
Upgrading the IBM i operating system to a new release can be done on one node at a time. Similar to the PTF installation process, the operating system can be upgraded on the secondary node, replication resumed, a role swap performed, and then the operating system can be upgraded on the new secondary node. This process allows an IBM i operating system upgrade without ending the production environment.
There are restrictions when doing a switchover of an IASP between nodes at
different releases of IBM i. If an IASP is switched from a
node running an older release of IBM i to a node running a
newer release of IBM i, when it is made available on the node
running the newer release of IBM i, its internal contents are
changed and it can no longer be made available on a node running an older release of IBM i. This restriction must be considered during your upgrade planning if you are using an IFS IASP in your Db2 Mirror environment.
Support for Live Partition Mobility
Live Partition Mobility (LPM) of a Db2 Mirror node is supported on POWER9™ and firmware level 940. With the 940 firmware, a Single Root I/O Virtualization (SR-IOV) logical port is allowed to be assigned to an IBM i partition in restricted I/O mode. Before LPM is performed on either the primary or secondary node, suspend Db2 Mirror replication. Then, the SR-IOV logical port must be removed from the node by using Dynamic Logical Partitioning (DLPAR). After the node is migrated to the new server by using LPM, add the SR-IOV port back to the node. While the node does not have an SR-IOV RoCE logical port, the Db2 Mirror primary node has a replication state of TRACKING and the secondary node has a replication state of BLOCKED. After the SR-IOV logical port is added back to the configuration, Db2 Mirror replication can be resumed.