Recovering a Database using Disaster Recovery

There are three ways in which a Disaster Recovery configuration might fail:

• The link between the master and slave systems might fail.
• The slave system or database might fail, or might need to be shut down for maintenance.
• The master system or database might fail, or might need to be shut down for maintenance.

In the first two cases, the master database can continue as normal and the slave database will normally be automatically brought up to date when the link is re-established or the slave system or database is working again. See Recovery from DR Link or Slave System Failure.

In the third case, you may need to make the slave database active. Also, once the master database is working again, you will need to restore the master from the slave. See Recovery from Master Database Failure.

Recovery from DR Link or Slave System Failure

• If the network link fails, simply wait until the link is re-established — the slave database will be automatically updated with the latest clean logs.

• If one of the clean logs is missing, do the following:

  1. On the master host, use tlmenu to save the master database.
  2. Transfer the file save to the slave system.
  3. On the slave host, use tlmenu to restore the slave database.

  4. On the slave host, use option 2 (Start DR Slave Synchronisation) on the tlmenu Disaster Recovery Configuration and Maintenance menu to restart synchronisation.

Recovery from Master Database Failure

1. If you need to make the slave database active do the following on the slave host:

   1. Use tlmenu to start transaction logging on the slave database.
   2. On the slave host, use option 3 (Stop DR Slave Synchronisation) on the tlmenu Disaster Recovery Configuration and Maintenance menu to stop synchronisation.
   3. Reconfigure the network to allow users to log on to the slave database.
2. On the slave host, use tlmenu to save the slave database.
3. On the master host, use tlmenu to rebuild the database and restore the save from the slave database.

4. If the slave database has been active during the previous step, do the following:

   1. On the master host, use tlmenu to configure the master database to act as a slave to the slave database.
   2. On the master host, use option 2 (Start DR Slave Synchronisation) on the tlmenu Disaster Recovery Configuration and Maintenance menu to start synchronising the master database to the slave.
   3. Wait until the two databases are synchronised. You can use option 4 (Show DR Status) on the tlmenu Disaster Recovery Configuration and Maintenance menu to check — the databases are synchronised if the current local clean log and last known remote clean log are the same, and no clean logs are available.
   4. At a convenient time, log all users off of the slave database.
   5. Switch clean logs on the slave database to save the final log and make it available for transfer to the master.
   6. Stop transaction logging on the slave database.
   7. On the master host, check that the two databases are synchronised and then stop synchronisation.
   8. Start transaction logging on the master database.
   9. Reconfigure the network to allow users onto the master database.
   10. On the slave host, start synchronising the slave to the master.