From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/transapp_journal.html | 83 +++++++++++++------------ 1 file changed, 43 insertions(+), 40 deletions(-) (limited to 'docs/programmer_reference/transapp_journal.html') 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 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 11. - Berkeley DB Transactional Data Store Applications -	Chapter 11. Berkeley DB Transactional Data Store Applications	Next

@@ -39,19 +37,21 @@

- 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. -

+ 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. +

- 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: -

+ 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: +

    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

- 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: -

+ 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: +

 mv DBHOME/log.000000XXX my-temporary-log-file

+ 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. +

+ If recovery is not successful, then you must perform a + catastrophic recovery from a previous backup. +

+ This situation has been shown to occur when using ext3 in + writeback mode, but other journaling filesystems could exhibit + similar behavior. +

- 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. -

- If recovery is not successful, then you must perform a catastrophic - recovery from a previous backup. -

- This situation has been shown to occur when using ext3 in writeback - mode, but other journaling filesystems could exhibit similar behavior. -

- 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. -

+ 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. +

-- cgit v1.2.1