1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
<?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>
|
