<p>Instead of synchronizing with the new master, it is sometimes possible
for a client to synchronize with another client. Berkeley DB initiates
synchronization at the client by sending a request message via the
transport call-back function of the communication infrastructure. The
message is destined for the master site, but is also marked with a
<ahref="../api_reference/C/reptransport.html#transport_DB_REP_ANYWHERE"class="olink">DB_REP_ANYWHERE</a> flag. The application may choose to send such
a request to another client, or to ignore the flag, sending it to its
indicated destination.</p>
<p>Furthermore, when the other client receives such a request it may be
unable to satisfy it. In this case it will reply to the requesting
client, telling it that it is unable to provide the requested
information. The requesting client will then re-issue the request.
Additionally, if the original request never reaches the other client,
the requesting client will again re-issue the request. In either of
these cases the message will be marked with the <ahref="../api_reference/C/reptransport.html#transport_DB_REP_REREQUEST"class="olink">DB_REP_REREQUEST</a>
flag. The application may continue trying to find another client to
service the request, or it may give up and simply send it to the master
(that is, the environment ID explicitly specified to the transport
function).</p>
<p>
Replication Manager allows an application to designate one or more
remote sites (called its "peers") to receive client-to-client requests.
You do this by setting the <codeclass="literal">DB_REPMGR_PEER</code> parameter
using the <ahref="../api_reference/C/dbsite_set_config.html"class="olink">DB_SITE->set_config()</a> method. Replication Manager always tries
to send requests marked with the <ahref="../api_reference/C/reptransport.html#transport_DB_REP_ANYWHERE"class="olink">DB_REP_ANYWHERE</a> flag to a peer, if
available. However, it always sends a <ahref="../api_reference/C/reptransport.html#transport_DB_REP_REREQUEST"class="olink">DB_REP_REREQUEST</a> to the master
site.
</p>
<p>Base API applications have complete freedom
in choosing where to send these <ahref="../api_reference/C/reptransport.html#transport_DB_REP_ANYWHERE"class="olink">DB_REP_ANYWHERE</a> requests, and
in deciding how to handle <ahref="../api_reference/C/reptransport.html#transport_DB_REP_REREQUEST"class="olink">DB_REP_REREQUEST</a>.</p>
<p>The delayed synchronization and client-to-client synchronization
features allow applications to do load balancing within replication
groups. For example, consider a replication group with 5 sites, A, B,
C, D and E. Site E just crashed, and site A was elected master. Sites
C and D have been configured for delayed synchronization. When site B
is notified that site A is a new master, it immediately synchronizes.
When B finishes synchronizing with the master, the application calls the
<ahref="../api_reference/C/repsync.html"class="olink">DB_ENV->rep_sync()</a> method on sites C and D to cause them to synchronize as well.
Sites C and D (and E, when it has finished rebooting) can send their
requests to site B, and B then bears the brunt of the work and
network traffic for synchronization, making master site A available to
handle the normal application load and any write requests paused by
<p>Clients in the process of synchronizing with the master block access to
Berkeley DB operations during some parts of that process.
By default, most Berkeley DB methods will block until
client synchronization is complete, and then the method call proceeds.</p>
<p>Client applications which cannot wait and would prefer an immediate
error return instead of blocking, should call the
<ahref="../api_reference/C/repconfig.html"class="olink">DB_ENV->rep_set_config()</a> method with the <ahref="../api_reference/C/repconfig.html#config_DB_REP_CONF_NOWAIT"class="olink">DB_REP_CONF_NOWAIT</a> flag. This
configuration causes <ahref="../api_reference/C/db.html"class="olink">DB</a> method calls to immediately return a
<ahref="../api_reference/C/dbput.html#dbput_DB_REP_LOCKOUT"class="olink">DB_REP_LOCKOUT</a> error instead of blocking, if the client is
<p>Clients attempting to synchronize with the master may discover that
synchronization is not possible because the client no longer has any
overlapping information with the master site. By default, the master and
client automatically detect this state and perform an internal initialization
of the client. Because internal initialization requires transfer of
entire databases to the client, it can take a relatively long period of
time and may require database handles to be reopened in the client
applications.</p>
<p>Client applications which cannot wait or would prefer
to do a hot backup instead of performing internal initialization, should
call the <ahref="../api_reference/C/repconfig.html"class="olink">DB_ENV->rep_set_config()</a> method to turn off the <ahref="../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
<ahref="../api_reference/C/repmessage.html#repmsg_DB_REP_JOIN_FAILURE"class="olink">DB_REP_JOIN_FAILURE</a> to the application instead of performing
