diff options
Diffstat (limited to 'docs/programmer_reference/rep_init.html')
| -rw-r--r-- | docs/programmer_reference/rep_init.html | 100 |
1 files changed, 59 insertions, 41 deletions
diff --git a/docs/programmer_reference/rep_init.html b/docs/programmer_reference/rep_init.html index 51865945..8678124f 100644 --- a/docs/programmer_reference/rep_init.html +++ b/docs/programmer_reference/rep_init.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="rep_mastersync.html">Prev</a> </td> - <th width="60%" align="center">Chapter 12. - Berkeley DB Replication - </th> + <th width="60%" align="center">Chapter 12. Berkeley DB Replication </th> <td width="20%" align="right"> <a accesskey="n" href="rep_bulk.html">Next</a></td> </tr> </table> @@ -38,47 +36,66 @@ </div> </div> </div> - <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_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to - turn off the <a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_AUTOINIT" class="olink">DB_REP_CONF_AUTOINIT</a> flag. Turning off this - configuration flag causes Berkeley DB to - return <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_JOIN_FAILURE" class="olink">DB_REP_JOIN_FAILURE</a> to the application's <a href="../api_reference/C/repmessage.html" class="olink">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> + 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_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to turn off the + <a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_AUTOINIT" class="olink">DB_REP_CONF_AUTOINIT</a> flag. Turning off this configuration + flag causes Berkeley DB to return <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_JOIN_FAILURE" class="olink">DB_REP_JOIN_FAILURE</a> to the + application's <a href="../api_reference/C/repmessage.html" class="olink">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> <div class="orderedlist"> <ol type="1"> - <li>Do an archival backup of the master's environment, as described in -<a class="xref" href="transapp_archival.html" title="Database and log file archival">Database and log file archival</a>. The backup can either be a conventional backup or a hot -backup.</li> - <li>Copy the archival backup into a clean environment directory on the -client.</li> - <li>Run catastrophic recovery on the client's new environment, as described -in <a class="xref" href="transapp_recovery.html" title="Recovery procedures">Recovery procedures</a>.</li> - <li>Reconfigure and reopen the environment as a client member of the -replication group.</li> + <li> + Do an archival backup of the master's environment, + as described in <a class="xref" href="transapp_archival.html" title="Database and log file archival">Database and log file + archival</a>. The backup can + either be a conventional backup or a hot + backup. + </li> + <li> + Copy the archival backup into a clean environment + directory on the client. + </li> + <li> + Run catastrophic recovery on the client's new + environment, as described in <a class="xref" href="transapp_recovery.html" title="Recovery procedures">Recovery procedures</a>. + </li> + <li> + Reconfigure and reopen the environment as a client + member of the replication group. + </li> </ol> </div> - <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="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility or the <a href="../api_reference/C/logarchive.html" class="olink">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> + <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="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility or the <a href="../api_reference/C/logarchive.html" class="olink">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> </div> <div class="navfooter"> <hr /> @@ -91,7 +108,8 @@ necessary.</p> <td width="40%" align="right"> <a accesskey="n" href="rep_bulk.html">Next</a></td> </tr> <tr> - <td width="40%" align="left" valign="top">Synchronizing with a master </td> + <td width="40%" align="left" valign="top">Synchronizing with a + master </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> |