<!--$Id: logonly.html,v 1.2 2004/03/30 01:22:56 jtownsen Exp $--> <!--Copyright 1997-2003 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="../rep/elect.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/trans.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p> <h3 align=center>Log file only clients</h3> <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 of the log files, so that in the event of master failure, a copy of the logs is available.</p> <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> <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> <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> <p>In all other ways, a log-file-only site behaves as other replication clients do. It should have at least one 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 method.</p> <table width="100%"><tr><td><br></td><td align=right><a href="../rep/elect.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/trans.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2003</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font> </body> </html>