Berkeley DB Reference Guide: Transaction Protected Applications
Recovery and filesystem operations
Filesystem operations, e.g., moving the database environment to a different machine or file creation, deletion or renaming, cannot be transaction protected. For this reason, files cannot be re-created, deleted or renamed as part of the recovery process.
If recovery cannot find a database file referenced in the log, it will output a warning message that it was unable to locate a file it expected to find. This message is only a warning, as the file may have subsequently been deleted as part of normal database operations before the failure occurred, and so cannot be known to be a problem.
Note that committed transactions that involved these missing files are rolled forward, even though the files were not found. If the files were not intentionally deleted (e.g., they were created after the last database snapshot, but were lost during a failure), they must be manually created (using db_open), and then recovery must be redone.
Generally, it is simplest to perform filesystem operations at the same time as making a snapshot of the database. To perform filesystem operations:
- Cleanly shutdown database operations.
- Rename, create or delete files.
- Make a snapshot of the database.
- Restart database applications.
To cleanly shutdown database operations, all applications accessing the database environment must be shutdown and a transaction checkpoint must be taken. If the applications are not implemented such that they can be shutdown gracefully (i.e., closing all references to the database environment), recovery must be performed after all applications have been killed to ensure that the underlying databases are consistent on disk.
Future versions of Berkeley DB are expected to remove the restriction that database files must be manually created before recovery is performed.
