Scenario: Recovery for remote journaling

 

This scenario describes a hot-backup environment in which the local system, JKLINT fails. It is necessary to restore the local system, and synchronize it with the remote system, JKLINT2.

Details: Recovery for remote journaling scenario has step-by-step instructions for recovering from this failure this scenario describes.

This scenario, and the details for this scenario, only discuss database physical files. All the concepts, however, apply to any journaled object type.

 

Example remote journal environment for hot-backup recovery

The following figure illustrates the hot-backup environment for JKLINT and JKLINT2. The following items list considerations for this environment:

• The remote journal BJ2 is only active after JKLINT fails. JKLINT2 assumes the role of primary system and JKLINT is running again (as the secondary system).

• Journal receivers are not specifically called out in the figure. They have been omitted in an attempt to simplify the scenario and to focus on the recovery steps for the database. Where necessary, processing specific to journal receivers is referred to in the scenario.

• Likewise, library redirection for the journals and journal receivers is not specifically called out in the figure. Again, this is omitted in an attempt to simplify the scenario. In the scenario, the libraries for any of the journals or journal receivers could be redirected to a library that is different from that being used for the corresponding objects on the other system.

• The figure simply refers to the original data in the figure as DB on the primary system JKLINT and DB' as the data replica on the backup system JKLINT2. DB can be one or more journaled objects, and DB' contains a replica for each of the journaled objects in DB.

For simplicity, the scenario below treats DB as a single database file and DB' as its replica.

The following items describe the scenario at the time JKLINT fails:

• System JKLINT is the primary system.

• The original data that is denoted by DB is journaled to an active local journal PJ1.

• Remote journal BJ1 on backup system JKLINT2 is active, and unless otherwise noted, is synchronously receiving journal entries from journal PJ1.

• A hot-backup application apply, not shown in the diagram, is asynchronously replaying, or applying, the changes to the data replica, DB'.

• The data replica DB' is journaled to local journal PJ2 on system JKLINT2.

  The journal state for journal PJ2 is *STANDBY.

• Remote journal BJ2 has a journal state of *INACTIVE (journal entries are not replicated to it). Remote journal BJ2 is only active when accepting the data changes back from system JKLINT2. This occurs after system JKLINT2 had been promoted to assume the role of the primary system due to a planned or unplanned outage of system JKLINT, and after system JKLINT has resumed operations.

• The primary system, JKLINT, has failed.

• The decision has been made to switch-over to the backup system, JKLINT2.

 

Parent topic:

Scenarios: Remote journal management and recovery

Related concepts
Confirmed and unconfirmed journal entries Remote journal considerations when restarting the server

Related tasks
Details: Recovery for remote journaling scenario

Related information
Scenario: Hot-backup environment