File: transapp_journal.html

package info (click to toggle)
db5.3 5.3.28%2Bdfsg2-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 158,500 kB
  • sloc: ansic: 448,411; java: 111,824; tcl: 80,544; sh: 44,264; cs: 33,697; cpp: 21,604; perl: 14,557; xml: 10,799; makefile: 4,077; javascript: 1,998; yacc: 1,003; awk: 965; sql: 801; erlang: 342; python: 216; php: 24; asm: 14
file content (109 lines) | stat: -rw-r--r-- 4,833 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Using Recovery on Journaling Filesystems</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="transapp.html" title="Chapter 11.  Berkeley DB Transactional Data Store Applications" />
    <link rel="prev" href="transapp_hotfail.html" title="Hot failover" />
    <link rel="next" href="transapp_filesys.html" title="Recovery and filesystem operations" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 11.2.5.3</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Using Recovery on Journaling Filesystems</th>
        </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>
          <td width="20%" align="right"> <a accesskey="n" href="transapp_filesys.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="transapp_journal"></a>Using Recovery on Journaling Filesystems</h2>
          </div>
        </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>
      <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
    PANIC: Invalid argument
    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>
      <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>
    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 />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="transapp_hotfail.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="transapp.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="transapp_filesys.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Hot failover </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Recovery and filesystem operations</td>
        </tr>
      </table>
    </div>
  </body>
</html>