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 nuochk tool, which can validate and attempt to repair database archives.

If an SM fails to start, the first step should be to run

nuochk --repair

More information can be found here.

If nuochk 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 analyzed with nuochk after being taken to ensure validity.


Have more questions? Submit a request