- Berkeley DB Reference Guide:
- Transaction Protected Applications
|
|
When running in a transaction-protected environment, database creation and deletion are logged as stand-alone transactions internal to Berkeley DB. That is, for each such operation a new transaction is begun and aborted or committed internally, so that they will be recovered during recovery.
The Berkeley DB API supports removing and renaming files. Renaming files is supported by the DB->rename method, and removing files by the DB->remove method. Berkeley DB does not permit specifying the DB_TRUNCATE flag when opening a file in a transaction protected environment. This is an implicit file deletion, but one that does not always require the same operating system file permissions as does deleting and creating a file.
If you have changed the name of a file or deleted it outside of the Berkeley DB library (e.g., you explicitly removed a file using your normal operating system utilities), then it is possible that recovery will not be able to find a database referenced in the log. In this case, db_recover will produce a warning message saying it was unable to locate a file it expected to find. This message is only a warning, as the file may have been subsequently deleted as part of normal database operations before the failure occurred, and so is not necessarily a problem.
Generally, any filesystem operations that are performed outside the Berkeley DB interface should be performed at the same time as making a snapshot of the database. To perform filesystem operations correctly:
To shutdown database operations cleanly, 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.
While this step is not strictly necessary, it is strongly recommended. If this step is not performed, recovery from catastrophic failure will require that recovery first be performed up to the time of the filesystem operations, the filesystem operations be redone, and then recovery be performed from the filesystem operations forward.
|
|