diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/transapp_journal.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/transapp_journal.html')
| -rw-r--r-- | docs/programmer_reference/transapp_journal.html | 83 |
1 files changed, 43 insertions, 40 deletions
diff --git a/docs/programmer_reference/transapp_journal.html b/docs/programmer_reference/transapp_journal.html index 760144a2..2576043d 100644 --- a/docs/programmer_reference/transapp_journal.html +++ b/docs/programmer_reference/transapp_journal.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="transapp_hotfail.html">Prev</a> </td> - <th width="60%" align="center">Chapter 11. - Berkeley DB Transactional Data Store Applications - </th> + <th width="60%" align="center">Chapter 11. Berkeley DB Transactional Data Store Applications </th> <td width="20%" align="right"> <a accesskey="n" href="transapp_filesys.html">Next</a></td> </tr> </table> @@ -39,19 +37,21 @@ </div> </div> <p> - In some cases, the use of meta-data only journaling file systems can - lead to log file corruption. The window of vulnerability is quite - small, but if the operating system experiences an unclean shutdown - while Berkeley DB is creating a new log file, it is possible that upon - file system recovery, the system will be in a state where the log file - has been created, but its own meta-data has not. -</p> + In some cases, the use of meta-data only journaling file + systems can lead to log file corruption. The window of + vulnerability is quite small, but if the operating system + experiences an unclean shutdown while Berkeley DB is creating + a new log file, it is possible that upon file system recovery, + the system will be in a state where the log file has been + created, but its own meta-data has not. + </p> <p> - When a log file is corrupted to this degree, normal recovery can fail - and your application may be unable to open your environment. Instead, - an error something like this is issued when you attempt to run normal - recovery on environment open: -</p> + When a log file is corrupted to this degree, normal + recovery can fail and your application may be unable to open + your environment. Instead, an error something like this is + issued when you attempt to run normal recovery on environment + open: + </p> <pre class="programlisting"> Ignoring log file: /var/dblog/log.0000000074: magic number 6c73732f, not 40988 Invalid log file: log.0000000074: Invalid argument @@ -59,32 +59,35 @@ process-private: unable to find environment txn_checkpoint interface requires an environment configured for the transaction subsystem </pre> - <p> - In this case, it may be possible to successfully recover the - environment by ignoring the log file that was being created — to - do this, rename the log file with the highest number to a temporary - name: -</p> + <p> + In this case, it may be possible to successfully recover + the environment by ignoring the log file that was being + created — to do this, rename the log file with the + highest number to a temporary name: + </p> <pre class="programlisting"> mv DBHOME/log.000000XXX my-temporary-log-file </pre> + <p> + and try running normal environment recovery again. If + recovery is successful, and your application is able to open + the environment, then you can delete the log file that you + renamed. + </p> + <p> + If recovery is not successful, then you must perform a + catastrophic recovery from a previous backup. + </p> + <p> + This situation has been shown to occur when using ext3 in + writeback mode, but other journaling filesystems could exhibit + similar behavior. + </p> <p> - and try running normal environment recovery again. If recovery is - successful, and your application is able to open the environment, then - you can delete the log file that you renamed. -</p> - <p> - If recovery is not successful, then you must perform a catastrophic - recovery from a previous backup. -</p> - <p> - This situation has been shown to occur when using ext3 in writeback - mode, but other journaling filesystems could exhibit similar behavior. -</p> - <p> - To be absolutely certain of your application's ability to recover your - environment in the event of a system crash, either use non-journaling - filesystems, or use a journaling filesystem in a safe (albeit slower) - configuration, such as ext3 in ordered mode. -</p> + To be absolutely certain of your application's ability to + recover your environment in the event of a system crash, + either use non-journaling filesystems, or use a journaling + filesystem in a safe (albeit slower) configuration, such as + ext3 in ordered mode. + </p> </div> <div class="navfooter"> <hr /> |