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
|
<!--$Id: logonly.html,v 1.1.1.1 2003/11/20 22:14:20 toshok Exp $-->
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Log file only clients</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
</head>
<body bgcolor=white>
<table width="100%"><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></h3></td>
<td align=right><a href="../../ref/rep/elect.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/trans.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p>
<h1 align=center>Log file only clients</h1>
<p>Applications wanting to use replication to support recovery after
catastrophic failure of the master may want to configure a site as a
logs-file-only replica. Such clients cannot respond to read (or write)
queries but they still receive a complete copy the log files, so that in the
event of master failure, a copy of the logs is available.
<p>Log file only clients are configured like other client sites, except
they should specify the <a href="../../api_c/rep_start.html#DB_REP_LOGSONLY">DB_REP_LOGSONLY</a> flag to the
<a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> method and should specify a priority of 0 to the
<a href="../../api_c/rep_elect.html">DB_ENV->rep_elect</a> method.
<p>There are two ways to recover using a log-file-only replica.
The simplest way is to copy the log files from the log-file-only
replica onto another site (either master or replica) and run catastrophic
recovery there. If that is not an option, then
recovery must be run on the log-file-only replica, using the log files
that have accumulated there.
If the log files are entirely
self-contained, that is, they start with log file number 1, then a log
replica can simply run catastrophic recovery. Obviously, if there are
a large number of log files in this case, recovery may take a long time.
If the log files are not self-contained, an archival copy of the
databases must first be restored onto the replica before running
catastrophic recovery. In the latter case (that is, running recovery
on the log-file-only replica), once the site returns to being a log-file-only
replica, the database files on the log-file-only replica should be removed,
and if the log files do not begin with log file number 1,
a new set of archival databases should be created from
the current master.
<p>More specifically, the log files accumulating on the log-file-only
replica can take the place of the log files described in
<i>catastrophic recovery</i> section of the
<a href="../../ref/transapp/recovery.html">Recovery procedures</a> Berkeley DB
Reference Guide.
<p>In all other ways, a log-file-only site behaves as other replication
clients do. It should have a thread or process receiving messages and
passing them to <a href="../../api_c/rep_message.html">DB_ENV->rep_process_message</a> and must respond to all returns
described for that interface.
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/rep/elect.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/trans.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
</body>
</html>
|
