Restoring Database Replicas


Occasionally, a replica is lost. This loss is usually due to a hardware failure (for example, disk crash), a software failure (for example, OS-level file system corruption), or a human error. If an unreplicated database is lost, you can restore a recent copy from backup and resume development work. The changes made between the time of the backup and the time of the failure are not recoverable.

Similarly, if you lose a replica, you can restore a recent copy from backup. But matters are more complicated:

Because this procedure involves substantial effort, it is intended for situations where serious damage has occurred. (For example, the disk containing a replica is unusable.)

Restoring a Replica from Backup

To restore a replica from backup:

  1. Use your vendor database tools to restore a copy of the replicated database from backup.
  2. Use the restorereplica command to start the restoration procedure.
  3. This command places a special lock on the replica. Between this point and the completion of Step 6, the syncreplica –import command adjusts the lock temporarily to permit application of the update, and then restores the full lock. During this time, only syncreplica –import can modify the replica.

  4. Verify that all update packets have been processed at their destination replicas.
  5. At the restored replica, generate update packets for all other replicas in the family, and send the packets to the sibling replicas.
  6. You can send the packets using your standard synchronization method. To recover the replica more quickly, create the packets with syncreplica –export –fship.

    Because your replica is in the special restoration state, each outgoing update packet includes a special request for a return acknowledgment. It also includes your replica’s old epoch numbers, which are now its current epoch numbers, by virtue of the restoration in Step 1. Each destination replica uses these numbers to roll back its row for your replica.

  7. Wait for each replica in the family to send an update packet to the restored replica. As in Step 4, you can accelerate the creation and delivery of the update packets.
  8. Collectively, these update packets include all the operations that occurred between the time of the backup and the last update that your replica sent out before its storage was lost, including operations that originated at your replica. (The packets also include more recent operations that originated at other replicas.) In addition, each incoming packet includes the requested return acknowledgment from the sending host.

  9. Process the incoming update packets with syncreplica –import. When your replica has received return acknowledgments from all other replicas in its family, syncreplica –import reports that restoration of the replica is complete:
  10. Database <name> is unlocked after restoration.

Development work in the replica can now resume.