Scenario: Data replication environment for remote journals

Typical data replication environment with remote journal function

How the data replication environment works

Local objects, F1, F2, and F3, on JKLINT are journaled to local journal JRN in library JLB1. A remote journal is defined on JKLINT2, where JRN has been redirected to library JLB2. This remote journal receives journal entries from the local journal on JKLINT. A hot-backup application apply replays the changes to the data replica on system JKLINT2.

The data replica is journaled to a local journal, JRN in library JLB1, for system recovery purposes only, so this journal must be in active state. If system JKLINT2 fails, the system performs recovery for the objects by using this local journal.

A hot-backup application assists in replicating data from one system to another. The hot-backup application apply is only performing the replay of operations to the data replica on the target system.

Since this scenario is for a data replication environment, the hot-backup application does not perform a switch-over to the backup system. See Scenario: Hot-backup environment for more details about hot-backup applications applies and hot-backup switch-overs.

How to establish the data replication environment for JKLINT and JKLINT2

The objects and local journal on JKLINT are already assumed to exist. The journal state for the local journal is also assumed to be active. The communications environment and associated RDB entries already exist and are established.

Establishing the data replication environment for JKLINT and JKLINT2 requires the following:

1. Create the remote journal on JKLINT2, and specify library redirection. Library redirection indicates that the journal's library, JLB1 on JKLINT, is redirected to library JLB2 on JKLINT2. The journal receiver's library, RLB1 on JKLINT, is redirected to library RLB2 on JKLINT2.

   After this step, the remote journal exists, but no receiver is currently attached.

2. To establish a clean breakpoint, perform a change journal operation to attach a new journal receiver at this time.
   Note: The next step restores local journal JRN in library JLB1 and attaches receiver X1002 in library RLB1. It then restores the objects, and starts journaling for the objects to the restored local journal.
3. Save the local journal and objects from JKLINT and restore them to JKLINT2. This primes the data replica and establishes the local journaling environment on JKLINT2.
4. Activate the remote journal on system JKLINT2. Specify that the remote journal must start with the attached receiver. Since no receiver is attached to the remote journal, the receiver that is currently attached to the local journal on JKLINT (X2) is created on JKLINT2. This receiver is then attached to the remote journal. Journal entries are replicated, starting with the first journal entry in receiver X2.

   An additional parameter on the Change Journal State (QjoChangeJournalState) API and Change Remote Journal (CHGRMTJRN) command indicates whether the remote journal function is to be maintained synchronously or asynchronously. Depending on how the remote journal is maintained, other parameters may also apply.

5. The hot-backup application apply process receives or retrieves journal entries from the remote journal, starting with the entries that were deposited after the data was saved and primed into the data replica. The process then starts replaying the changes that are contained in these journal entries to the data replica.

Normal run-time environment for the data replication environment

You can activate and inactivate the replication of journal entries to the remote journal as needed. Each time you activate the remote journal, *ATTACHED is specified as the point in the receiver chain to start receiving journal entries. The system checks the currently attached remote journal receiver for journal entries and replicates the next journal entry in sequence.

You must specify the delivery mode when activating the remote journal. If needed, the delivery mode can be different on each activation of the remote journal.

Change journal operations that attach a new receiver to the local journal on system JKLINT are performed by the remote journal function as required on the target system. The remote journal function attaches the associated receivers to the remote journal automatically. If the remote journal is being maintained synchronously, the change journal operation to attach a new receiver is essentially a coordinated operation between the source and target systems. If the remote journal is being maintained asynchronously, the change journal operation to attach a new receiver on the target system is performed differently. In this case, it is triggered when the journal entry with journal code 'J' and entry type 'PR' is received by the remote journal on the target system.

The hot-backup application apply continues to replay changes to the data replica as received or retrieved from the receivers associated with the remote journal.

If needed, you can delete the receivers that are associated with the local journal on JKLINT when each receiver is replicated to JKLINT2. Sharon can accomplish this by specifying automatic deletion of journal receivers or manually deleting the receivers on JKLINT.

You can save the receivers from JKLINT2. If necessary, you can use the receivers for recovery of the original data on system JKLINT at a later time.

See Delete journal receivers for more information.

Data replication recovery if JKLINT fails

Recovery for JKLINT and JKLINT2 is simpler than environments that involve hot-backup because the hot-backup application does not switch-over to the backup system. What prevents the complications is an assumption that the hot-backup application apply logic will not receive and replay unconfirmed journal entries to the data replica if system JKLINT2 loses communications with system JKLINT. Therefore, the data replica on system JKLINT2 can never get ahead of the data on system JKLINT. This greatly simplifies data synchronization.