In this scenario, the remote journaling environment uses a hot-backup application that causes JKLINT2 to replace JKLINT in the case that JKLINT has a failure.
A hot-backup application typically performs the following:
- If the primary system fails, it performs a switch-over to the backup system. This function then logically promotes the backup system to assume the role of the primary system.
- After the failed primary system is restarted, it performs a switch-back operation so that the primary system can again assume the role of the primary system.
A hot-backup application apply defines the part of a hot-backup application that actually performs the replay operations to the data replica. This usually occurs on the backup system when maintaining a data replica.
The following figure describes a typical remote journal environment that is used for hot-backup purposes. The following occurs in this illustration:
- Server JKLINT is the primary server while JKLINT2 is the backup server.
- Server JKLINT journals objects to local journal JKLB1/JRN.
- Changes to those journaled objects are also journaled to remote journal JLB2/JRN on server JKLINT2.
- On JKLINT2 a hot backup-apply replays changes to the data replica. When the hot backup-apply replays these changes, JKLINT2 journals the changes to its own local journal, JLB1/JRN.
- If JKLINT fails, JKLINT2 assumes the role of primary server and all local journaling of changes to the data replica (now acting as the original data) continue on JKLINT2's local journal, JLB1/JRN.
- When it is time to switch the role of primary server back to JKLINT, JKLINT2 sends changes from its local journal, JLB1/JRN, to remote journal JLB2/JRN on server JKLINT (the transport from JKLINT2 to JKLINT is only used for this purpose).
- JKLINT then uses its remote journal, JLB2/JRN, to replay changes to the original data.
Typical hot-backup environment with remote journal function
How to establish the hot-backup environment
The steps to establish a hot-backup environment the are the same as establishing data replication environment except for this additional last step:
Sharon also establishes a remote journal JKLINT that is associated with the local journal that she creates on JKLINT2. This remote journal receives or retrieves the journaled changes that are made when JKLINT2 assumes the role of the primary system. This local journal and remote journal pair will only be used when replicating changes back to the original data. During normal run-time processing, the remote journal, JLB2/JRN, that is defined on JKLINT is not active. When it is not active, it is not receiving or retrieving journal entries from the local journal, JLB1/JRN, on JKLINT2.
Normal run-time environment for the hot-backup environment
The details for run-time environment for the hot-backup environment is the same as the data replication environment.Hot-backup recovery if JKLINT fails
If you use a hot-backup application where the logical ownership of the data is given to JKLINT2, recovery is more complicated. In this case, the hot-backup application logically promotes JKLINT to assume the role of the primary system. Recovery is more complicated because after JKLINT has completed its IPL, the remote journal function catch-up phase from the local journal on system JKLINT to the remote journal on system JKLINT2 will always allow a resynchronization of the two sets of data.
Data resynchronization is recovery processing that is performed during switch-back processing by a hot-backup application apply. This processing ensures that the original data is consistent with the data replica, and contains all the correct changes. The main objective of this, besides assuring data consistency, is to eliminate re-priming the original data from the data replica.
For details on recovering a hot-backup environment see Scenario: Recovery for remote journaling.