<!--$Id: init.so,v 1.6 2005/10/19 19:11:20 bostic Exp $-->
<!--Copyright (c) 1997,2008 Oracle. All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Initializing a new site</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,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><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></b></td>
<td align=right><a href="../rep/mastersync.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/bulk.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p align=center><b>Initializing a new site</b></p>
<p>By default, adding a new site to a replication group only requires the
client to join. Berkeley DB will automatically perform internal
initialization from the master to the client, bringing the client into
sync with the master.</p>
<p>However, depending on the network and infrastructure, it can be
advantageous in a few instances to use a "hot backup" to initialize a
client into a replication group. Clients not wanting to automatically
perform internal initialization should call the <a href="../../api_c/rep_config.html">DB_ENV->rep_set_config</a> method
with the <a href="../../api_c/rep_config.html#DB_REP_CONF_NOAUTOINIT">DB_REP_CONF_NOAUTOINIT</a> flag. This configuration flag
causes Berkeley DB to return <a href="../../api_c/rep_message.html#DB_REP_JOIN_FAILURE">DB_REP_JOIN_FAILURE</a> to the application's
<a href="../../api_c/rep_message.html">DB_ENV->rep_process_message</a> method instead of performing internal initialization.</p>
<p>To use a hot backup to initialize a client into a replication group,
perform the following steps:</p>
<ol>
<p><li>Do an archival backup of the master's environment, as described in
<a href="../../ref/transapp/archival.html">Database and log file
archival</a>. The backup can either be a conventional backup or a hot
backup.
<p><li>Copy the archival backup into a clean environment directory on the
client.
<p><li>Run catastrophic recovery on the client's new environment, as described
in <a href="../../ref/transapp/recovery.html">Recovery procedures</a>.
<p><li>Reconfigure and reopen the environment as a client member of the
replication group.
</ol>
<p>If copying the backup to the client takes a long time relative to the
frequency with which log files are reclaimed using the
<a href="../../utility/db_archive.html">db_archive</a> utility or the <a href="../../api_c/log_archive.html">DB_ENV->log_archive</a> method, it may be
necessary to suppress log reclamation until the newly restarted client
has "caught up" and applied all log records generated during its
downtime.</p>
<p>As with any Berkeley DB application, the database environment must be in a
consistent state at application startup. This is most easily assured
by running recovery at startup time in one thread or process; it is
harmless to do this on both clients and masters even when not strictly
necessary.</p>
<table width="100%"><tr><td><br></td><td align=right><a href="../rep/mastersync.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/bulk.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font>
</body>
</html>
