Archive Synchronization

For any given database, NuoDB recommends running two or more SMs to ensure high-availability and redundancy. Additional SMs do not typically make the database faster to read or write data. Additional TEs, on the other hand, can provide increased performance by allowing more queries to be run concurrently.

When running multiple SMs, by default, each archive contains a complete copy of the database. Each SM is thus a backup for the other SMs.

Multiple SMs automatically act as backups for each other. Consider this while scheduling explicit backups.

Multiple SMs act as backups for each other due to Archive Synchronization.

How it Works

Scenario: An SM needs to be taken down for maintenance, is scaled-in (because it is, temporarily not needed) or restarted due to a failure.

When the SM is restarted, it goes into the SYNC state. You can see this in the output of nuocmd show domain or nuocmd show database. In the SYNC state, the SM requests (from the already-running SMs in the database) a copy of all data that has changed since the last transaction it committed (just before going down).

Once the archive is up-to-date again, it switches to the RUNNING state and recommences managing data in the usual way.

Even if the entire archive has been lost (perhaps due to disk failure), an SM can be restarted with an empty archive and will use archive synchronization to import the entire database from the other SMs. In this way, the loss of an SM or its archive causes no database downtime or data loss.

Database Cloning

Scenario: Clone from a backup.

To create a new database from a backup:

  1. Initialize the first archive from the backup.

  2. Create the database (it will run a single SM).

  3. Once the first SM is up and running, start additional SMs. Each will use archive synchronization to populate their empty archives.

Catastrophic Failure

Scenario: All the archives belonging to all the SMs have failed.

In the unlikely event that all the archives in a database have been lost or corrupted, you can restore the database from your most recent backup in the same way as creating the clone database.

  1. If necessary, delete any remaining archive directories

  2. Restore one archive and restart its SM.

  3. Once the SM is up and running, start additional SMs as desired. They will SYNC from the first SM.

The same mechanism can be used to return a database to a known initial state during development and testing. Follow the steps below after completing the tests:

  1. Stop all the SMs.

  2. Delete all the archives.

  3. Restore one archive

  4. Restart its SM

  5. Then let any other SMs restore from the first SM.