Disaster Recovery Administration

Database Maintenance

• Always use tlmenu to delete clean logs from the master host; tlmenu will detect the presence of an active Disaster Recovery link and will delete or queue the clean logs for deletion as appropriate. Logs queued for deletion will be automatically deleted once they have been successfully applied to the slave database.
• The clean logs on the slave database can be deleted using tlmenu in the normal way.

• Clean logs are automatically deleted from the DR slave system once they have been successfully applied to the slave database.

Switching Between the Primary and Secondary on FailSafe

On FailSafe systems, the Disaster Recovery slave will automatically switch to work with whichever is the current primary system.

Problems

If a clean log is corrupt or missing, Disaster Recovery cannot continue. Problems are recorded as alerts (level 2) in the daemon log — you can set up a system alert if you wish to be informed of these events. To recover, you must save the master database and restore it on the slave; then resume DR operation.

Viewing the Disaster Recovery Status

Option 4 (Show DR Status) on the tlmenu Disaster Recovery Configuration and Maintenance menu allows you to monitor the Disaster Recovery link. The following shows a typical display:

Disaster Recovery link status for drtestslv at Jan 15 10:42:07
Link status last checked at Jan 15 10:41:53
    Current Synchronisation state is Active
    Current master database is 'drtestpri' on system 'gate9'
    Default master database is   'drtestpri' on system 'gate9'
    Alternate master database is 'drtestsec' on system 'gate10'

    Current local clean log is       'CLOG070111-04'
    Last Known remote clean log is   'CLOG070111-04'
        There are 0 clean logs available from the master database.
    Current operation: Receiving Clean Log Data (Image)

This shows a link to a failsafe pair (systems gate9 and gate10). The primary system (default master database) is currently gate9, with gate10 as the secondary (alternate master database). The current local clean log and the last known remote clean log are the same, and there are no clean logs available on the master database, showing that the slave is synchronised with the master.

The last line of the display shows the current operational mode of the slave system. This will be one of the following:

Connecting Attempting to connect to the master database. If the slave remains in this state for any length of time, there might be a problem with the Disaster Recovery link or the master database.

Connected Connection completed.

Waiting Waiting for a response from the master database.

Receiving Clean log Data (Image)
Transferring images from current clean log on the master database.

Receiving Clean log Data (Block)
Transferring older clean logs from the master database.

Restoring images Applying clean log images to the slave.

Disconnecting Disconnecting from the master database.

Sleeping The slave database is up to date and has disconnected. It sleeps for 30 seconds, and then reconnects to request clean log updates.