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.)
To restore a replica from backup:
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.
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.
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.
Database <name> is unlocked after restoration.
Development work in the replica can now resume.