Software reclone considerations

Edit online

A software reclone requires that replication is suspended between the two Db2® Mirror nodes or IASPs. The reclone must be initiated on the node in TRACKING state, or if both nodes are BLOCKED it must be initiated on the primary node. If the desired source node is not the primary node, the roles can be swapped using either the Db2 Mirror GUI or the QSYS2.SWAP_MIRROR_ROLES procedure. If the replication state is not ACTIVE, the FORCE action can be used.

Although it is not required to quiesce active work on either the source or copy node during the software reclone, it is recommended that user and application activity is quiesced on the copy node. The software reclone will fail if it is unable to obtain any lock on the copy node needed to delete objects. This failure leaves the copy node suspended until another reclone is completed. Some objects might have already been deleted on the copy node and will not be restored until another reclone is done.

While the software reclone is in progress, the following restrictions apply:
  • Replicated and non-replicated dependent objects on the copy node may not be available during portions of the software reclone as objects are deleted. The replicated objects are gradually reestablished on the copy node as the software reclone processing progresses.
  • Entries cannot be added or removed from the RCL.
  • Pending RCL entries cannot be changed or applied.

If a software reclone fails during after the initial environment validation step using the Db2 Mirror GUI or during the execution of the QSYS2.RECLONE_REPLICATED_OBJECTS procedure, both nodes will become suspended. To return to active replication, a successful software or hardware reclone would need to be completed.

Once the software reclone is complete, a final step of comparing libraries for differences should be done using either the Db2 Mirror GUI or the QSYS2.CONFIRM_RECLONED_LIBRARY_DIFFERENCES table function. This will ensure that there are no differences in replicated objects between the two nodes. The software reclone process does not prevent objects from being created, renamed, or moved during the reclone preparation phase. Therefore, it is a best practice to review any differences before and after the software reclone. During a software reclone, the OTL is cleared on both the source and copy nodes, so awareness of entries that will be lost should be reviewed prior to the software reclone.

Start of change

Journaling considerations

During software reclone, replicated journals on the copy node are deleted. The deletion of a journal affects journal receivers and remote journals associated with the replicated journals. The following actions are taken against replicated journals on the copy node as the software reclone progresses:
  • The replicated journal is deleted from the copy node. To delete the journal on the copy node:
    • Journal receivers are disassociated from the replicated journal on the copy node.
    • Activated remote journals attached to the replicated journal on the copy node are inactivated.
    • Remote journals are removed from the replicated journal on the copy node.
    • A row is written to the Object Tracking List (OTL) on the copy node for each journal receiver that is disassociated, each remote journal that is deactivated, and each remote journal that is removed. These OTL entries contain the information needed to reassociate the journal receivers and reestablish and reactivate the remote journal.
  • The replicated journal is saved from the source node and restored to the copy node. After the journal is restored:
    • Journal receivers that were disassociated from the replicated journal during the software reclone are reassociated with the journal.
    • If remote journals were removed from the replicated journal prior to the software reclone, the remote journals are reestablished.
    • If an active remote journal was attached to the replicated journal prior to the start of software reclone, the remote journal is reactivated.
    • The software reclone does not fail if there is a failure to reassociate a journal receiver, reestablish a remote journal, or reactivate a remote journal. If any of these actions fail, the OTL entry is updated with a failure message, and the OTL entry is deferred. If a failure occurs, correct the failure, and manually associate the journal receiver, add remote journaling, or activate remote journaling.

Remote journals associated with replicated journals on the source node are not affected. To avoid having remote journaling affected by a software reclone, remote journals can be associated with journals on the source node instead of the copy node.

End of change