2011-09-13 17:44:24 +00:00
|
|
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
|
|
|
<head>
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|
|
|
|
<title>Client to Client Transfer</title>
|
|
|
|
|
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
|
|
|
|
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
|
|
|
|
<link rel="start" href="index.html" title="Getting Started with Replicated Berkeley DB Applications" />
|
|
|
|
|
<link rel="up" href="addfeatures.html" title="Chapter 5. Additional Features" />
|
|
|
|
|
<link rel="prev" href="rywc.html" title="Read-Your-Writes Consistency" />
|
|
|
|
|
<link rel="next" href="bulk.html" title="Bulk Transfers" />
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
<div xmlns="" class="navheader">
|
|
|
|
|
<div class="libver">
|
2012-11-14 21:35:20 +00:00
|
|
|
|
<p>Library Version 11.2.5.3</p>
|
2011-09-13 17:44:24 +00:00
|
|
|
|
</div>
|
|
|
|
|
<table width="100%" summary="Navigation header">
|
|
|
|
|
<tr>
|
|
|
|
|
<th colspan="3" align="center">Client to Client Transfer</th>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td width="20%" align="left"><a accesskey="p" href="rywc.html">Prev</a> </td>
|
|
|
|
|
<th width="60%" align="center">Chapter 5. Additional Features</th>
|
|
|
|
|
<td width="20%" align="right"> <a accesskey="n" href="bulk.html">Next</a></td>
|
|
|
|
|
</tr>
|
|
|
|
|
</table>
|
|
|
|
|
<hr />
|
|
|
|
|
</div>
|
|
|
|
|
<div class="sect1" lang="en" xml:lang="en">
|
|
|
|
|
<div class="titlepage">
|
|
|
|
|
<div>
|
|
|
|
|
<div>
|
|
|
|
|
<h2 class="title" style="clear: both"><a id="c2ctransfer"></a>Client to Client Transfer</h2>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="toc">
|
|
|
|
|
<dl>
|
|
|
|
|
<dt>
|
|
|
|
|
<span class="sect2">
|
|
|
|
|
<a href="c2ctransfer.html#fmwrkpeerserver">Identifying Peers</a>
|
|
|
|
|
</span>
|
|
|
|
|
</dt>
|
|
|
|
|
</dl>
|
|
|
|
|
</div>
|
|
|
|
|
<p>
|
|
|
|
|
It is possible to use a replica instead of a master to synchronize another
|
|
|
|
|
replica. This serves to take the request load off a master that might otherwise
|
|
|
|
|
occur if multiple replicas attempted to synchronize with the master at the same
|
|
|
|
|
time.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
For best results, use this feature combined with the delayed synchronization
|
|
|
|
|
feature (see <a class="xref" href="addfeatures.html#delayedsync" title="Delayed Synchronization">Delayed Synchronization</a>).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
For example, suppose your replication group consists of four environments. Upon
|
|
|
|
|
application startup, all three replicas will immediately attempt to synchronize
|
|
|
|
|
with the master. But at the same time, the master itself might be busy with a heavy
|
|
|
|
|
database write load.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
To solve this problem, delay synchronization for two of the three replicas. Allow
|
|
|
|
|
the third replica to synchronize as normal with the master. Then, start
|
|
|
|
|
synchronization for each of the delayed replicas (since this is a manual process,
|
|
|
|
|
you can do them one at a time if that best suits your application).
|
|
|
|
|
Assuming you have configured replica to replica synchronization correctly, the
|
|
|
|
|
delayed replicas will synchronize using the up-to-date replica, rather than using
|
|
|
|
|
the master.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
When you are using the Replication Manager, you configure replica to replica synchronization by
|
|
|
|
|
declaring an environment to be a peer of another environment. If an
|
|
|
|
|
environment is a peer, then it can be used for synchronization purposes.
|
|
|
|
|
</p>
|
|
|
|
|
<div class="sect2" lang="en" xml:lang="en">
|
|
|
|
|
<div class="titlepage">
|
|
|
|
|
<div>
|
|
|
|
|
<div>
|
|
|
|
|
<h3 class="title"><a id="fmwrkpeerserver"></a>Identifying Peers</h3>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<p>
|
|
|
|
|
You can designate one replica to be a peer of
|
|
|
|
|
another for replica to replica synchronization.
|
|
|
|
|
You might want to do this if you have
|
|
|
|
|
machines that you know are on fast, reliable
|
|
|
|
|
network connections and so you are willing to
|
|
|
|
|
accept the overhead of waiting for
|
|
|
|
|
acknowledgments from those specific machines.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Note that peers are not required to be a
|
|
|
|
|
bi-directional. That is, just because machine A
|
|
|
|
|
declares machine B to be a peer, that does not mean
|
|
|
|
|
machine B must also declare machine A to be a peer.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
You declare a peer for the current environment
|
|
|
|
|
when you add that environment to the list of known
|
|
|
|
|
sites. You do this by
|
|
|
|
|
<span>specifying the
|
|
|
|
|
<code class="literal">DB_REPMGR_PEER</code> flag to
|
|
|
|
|
|
|
|
|
|
<span><code class="methodname">DbEnv::repmgr_add_remote_site()</code>.</span>
|
|
|
|
|
</span>
|
|
|
|
|
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="navfooter">
|
|
|
|
|
<hr />
|
|
|
|
|
<table width="100%" summary="Navigation footer">
|
|
|
|
|
<tr>
|
|
|
|
|
<td width="40%" align="left"><a accesskey="p" href="rywc.html">Prev</a> </td>
|
|
|
|
|
<td width="20%" align="center">
|
|
|
|
|
<a accesskey="u" href="addfeatures.html">Up</a>
|
|
|
|
|
</td>
|
|
|
|
|
<td width="40%" align="right"> <a accesskey="n" href="bulk.html">Next</a></td>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td width="40%" align="left" valign="top">Read-Your-Writes Consistency </td>
|
|
|
|
|
<td width="20%" align="center">
|
|
|
|
|
<a accesskey="h" href="index.html">Home</a>
|
|
|
|
|
</td>
|
|
|
|
|
<td width="40%" align="right" valign="top"> Bulk Transfers</td>
|
|
|
|
|
</tr>
|
|
|
|
|
</table>
|
|
|
|
|
</div>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|