Remote journal considerations when restarting the server

Considerations for restarting replication of journal entries

The replication of journal entries to each of the associated remote journals ends implicitly when the local system ends. To begin replicating journal entries to the remote journal, you must restart the remote journal on the target system. After an IPL or vary on operation, you are not required to reassociate the remote journals with the journal on the source system.

Considerations for main storage preservation

In addition to unconfirmed I/O for journal entries, you also need to consider the preservation of main storage for a failed system during recovery processing. Given certain system failures, main storage might or might not be preserved during the following IPL to recover from the system failure. Therefore, it is possible for journal entries to survive in a local journal after a system failure, even if the local or remote I/O was never performed for those journal entries.

Therefore, IPL recovery on a primary system might preserve changes that are not yet replicated to any of the remote journals, even the remote journals that are synchronously maintained. Scenario: Recovery for remote journaling demonstrates that you can use the remote journal function to account for journal entries that survive a system failure in this manner. These journal entries do not cause a total re-priming of the original data when switching back from a backup system which took over the role of the primary system.

In the scenario, when the system ends, the system does not return control to the application programs that are in the process of generating these surviving journal entries. Therefore, the application does not know whether or not any of operations completed when the system ends. Also, the application does not make dependencies or decisions on these operations. This includes dependencies or decisions by the application performing the operation or any other application that could be possibly dependent upon the data affected by the operation.

Because of this consideration, it is recommended that you journal both the before-images and after-images for any objects, if possible. With the before-images, the work can then be backed out after the IPL or vary on operation. If the data activity is not backed out after the IPL or vary on operation, the alternative is to re-prime the primary system data completely from the backup data which had assumed the role of the primary.

Considerations for when the target system ends

When remote journaling is active, if the target system ends whether normal or abnormal, journaling on the source system is not affected. The local system continues to deposit entries into the local journal without an error. The system sends a message to the message queue of the local journal to alert the operator that remote journaling ended. When the target is again available, you can reactivate remote journaling from the source system. When you activate remote journaling, the default is for the local system to start sending journal entries starting with the first entry the target system is missing. Additionally, you can specify that remote journaling automatically try to restart when the target system ends.

Considerations for commitment control

Commitment control, especially two-phase commitment control, can cause some additional considerations and potential complications. For example, if any of the entries that were preserved but not yet confirmed were a commit or a rollback operation, then the transaction will have to be reconciled accordingly between the primary system, and the backup system.

Considerations for journal caching

Journal caching affects remote journaling. Since journal entries are not sent to the target system right away, the number of journal entries that are not confirmed in a synchronous remote journal environment are always greater than if you are not using journal caching.