When starting a storage manager (SM) fails: recovering from corruption


What should be done when a NuoDB storage manager (SM) fails to start? What steps should be taken when starting to avoid corruption?



In most cases, restarting the engine is sufficient to recover from an SM crash. However, certain situations can leave the underlying archive (data) in an invalid state. This is referred to as "corruption". NuoDB supplies the nuoarchive tool, which can validate and attempt to repair database archives.

If an SM fails to start, the first step should be to run this command, pointing to the archive directory:

nuoarchive check --repair <archive_dir>

More information can be found here.

If nuoarchive is unable to repair the archive, the other SM archives should be analyzed. If there are no repairable archives, it's necessary to restore from a valid backup.

It's recommended that all backups be checked with nuoarchive after being taken to ensure validity.


Have more questions? Submit a request