mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
138 lines
6.6 KiB
HTML
138 lines
6.6 KiB
HTML
<?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">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</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>
|
||
constructing a <code class="classname">ReplicationHostAddress</code>
|
||
object that specifies <code class="literal">true</code> for the
|
||
<code class="literal">isPeer</code> parameter, and
|
||
then providing that object to
|
||
<code class="methodname">EnvironmentConfig.replicationManagerAddRemoteSite()</code>
|
||
when you add the remote site to the
|
||
local replication site.
|
||
</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>
|