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
110
111
112
113
114
115
116
117
118
|
<?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>Recovery and filesystem operations</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_journal.html" title="Using Recovery on Journaling Filesystems" />
<link rel="next" href="transapp_reclimit.html" title="Berkeley DB recoverability" />
</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">Recovery and filesystem operations</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="transapp_journal.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_reclimit.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_filesys"></a>Recovery and filesystem operations</h2>
</div>
</div>
</div>
<p>
The Berkeley DB API supports creating, removing and renaming files.
Creating files is supported by the <a href="../api_reference/C/dbopen.html" class="olink">DB->open()</a> method. Removing files is
supported by the <a href="../api_reference/C/envdbremove.html" class="olink">DB_ENV->dbremove()</a> and <a href="../api_reference/C/dbremove.html" class="olink">DB->remove()</a> methods. Renaming files
is supported by the <a href="../api_reference/C/envdbrename.html" class="olink">DB_ENV->dbrename()</a> and <a href="../api_reference/C/dbrename.html" class="olink">DB->rename()</a> methods. (There are
two methods for removing and renaming files because one of the methods
is transactionally protected and one is not.)
</p>
<p>
Berkeley DB does not permit specifying the <a href="../api_reference/C/dbopen.html#open_DB_TRUNCATE" class="olink">DB_TRUNCATE</a> 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 deleting and creating a file do.
</p>
<p>
If you have changed the name of a file or deleted it outside of the
Berkeley DB library (for example, 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 to which the log refers.
In this case, the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility will produce a warning message, saying
it was unable to locate a file it expected to find. This message is
only a warning because the file may have been subsequently deleted as
part of normal database operations before the failure occurred, so is
not necessarily a problem.
</p>
<p>
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,
do the following:
</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Cleanly shut down database operations.</p>
<p>To shut down database operations cleanly, all applications accessing
the database environment must be shut down and a transaction checkpoint
must be taken. If the applications are not implemented so they can be
shut down gracefully (that is, 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.</p>
</li>
<li>Perform the filesystem operations; for example, remove or rename one or
more files.</li>
<li>
<p>Make an archival snapshot of the database.</p>
<p>Although 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.</p>
</li>
<li>Restart the database applications.</li>
</ol>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="transapp_journal.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_reclimit.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Using Recovery on Journaling Filesystems </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Berkeley DB recoverability</td>
</tr>
</table>
</div>
</body>
</html>
|
