<!--$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>