1<!--$Id: init.so,v 1.6 2005/10/19 19:11:20 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Initializing a new site</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></b></td> 13<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> 14</td></tr></table> 15<p align=center><b>Initializing a new site</b></p> 16<p>By default, adding a new site to a replication group only requires the 17client to join. Berkeley DB will automatically perform internal 18initialization from the master to the client, bringing the client into 19sync with the master.</p> 20<p>However, depending on the network and infrastructure, it can be 21advantageous in a few instances to use a "hot backup" to initialize a 22client into a replication group. Clients not wanting to automatically 23perform internal initialization should call the <a href="/api_c/rep_config.html">DB_ENV->rep_set_config</a> method 24with the <a href="/api_c/rep_config.html#DB_REP_CONF_NOAUTOINIT">DB_REP_CONF_NOAUTOINIT</a> flag. This configuration flag 25causes Berkeley DB to return <a href="/api_c/rep_message.html#DB_REP_JOIN_FAILURE">DB_REP_JOIN_FAILURE</a> to the application's 26<a href="/api_c/rep_message.html">DB_ENV->rep_process_message</a> method instead of performing internal initialization.</p> 27<p>To use a hot backup to initialize a client into a replication group, 28perform the following steps:</p> 29<ol> 30<p><li>Do an archival backup of the master's environment, as described in 31<a href="/ref/transapp/archival.html">Database and log file 32archival</a>. The backup can either be a conventional backup or a hot 33backup. 34<p><li>Copy the archival backup into a clean environment directory on the 35client. 36<p><li>Run catastrophic recovery on the client's new environment, as described 37in <a href="/ref/transapp/recovery.html">Recovery procedures</a>. 38<p><li>Reconfigure and reopen the environment as a client member of the 39replication group. 40</ol> 41<p>If copying the backup to the client takes a long time relative to the 42frequency with which log files are reclaimed using the 43<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 44necessary to suppress log reclamation until the newly restarted client 45has "caught up" and applied all log records generated during its 46downtime.</p> 47<p>As with any Berkeley DB application, the database environment must be in a 48consistent state at application startup. This is most easily assured 49by running recovery at startup time in one thread or process; it is 50harmless to do this on both clients and masters even when not strictly 51necessary.</p> 52<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> 53</td></tr></table> 54<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 55</body> 56</html> 57
