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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
<?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>Replication FAQ</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="Berkeley DB Programmer's Reference Guide" />
<link rel="up" href="rep.html" title="Chapter 12. Berkeley DB Replication" />
<link rel="prev" href="rep_partition.html" title="Network partitions" />
<link rel="next" href="rep_ex.html" title="Ex_rep: a replication example" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 12.1.6.1</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Replication FAQ</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
<th width="60%" align="center">Chapter 12. Berkeley DB Replication </th>
<td width="20%" align="right"> <a accesskey="n" href="rep_ex.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="rep_faq"></a>Replication FAQ</h2>
</div>
</div>
</div>
<div class="orderedlist">
<ol type="1">
<li>
<p>
<span class="bold"><strong>Does Berkeley DB provide support
for forwarding write queries from clients to
masters?</strong></span>
</p>
<p>
No, it does not. In
general this protocol is left entirely to the
application. A Replication Manager application can use
message channels to implement this capability (see
<a class="xref" href="rep_ex_chan.html" title="Ex_rep_chan: a Replication Manager channel example">Ex_rep_chan: a Replication Manager channel example</a> for information
about a sample program that demonstrates this use of
message channels). For a Base API application, it is
possible to use the communications channels it
establishes for replication support to forward
database update messages to the master, since Berkeley
DB does not require those channels to be used
exclusively for replication messages.
</p>
</li>
<li>
<p>
<span class="bold"><strong>Can I use replication to
partition my environment across multiple
sites?</strong></span>
</p>
<p>
Yes, you can create partial views to accomplish
this. See <a class="xref" href="rep_partview.html" title="Replication views">Replication views</a> for more
information.
</p>
</li>
<li>
<p>
<span class="bold"><strong>I'm running with replication but
I don't see my databases on the client.</strong></span>
</p>
<p>
This problem may be the result of the application
using absolute path names for its databases, and the
pathnames are not valid on the client system.
</p>
</li>
<li>
<p>
<span class="bold"><strong>How can I distinguish Berkeley
DB messages from application messages?</strong></span>
</p>
<p>
Replication Manager provides its own communications
infrastructure for replication messages. You can
create message channels to pass application-specific
messages using this infrastructure (see <a class="xref" href="repmgr_channels.html" title="Using Replication Manager message channels">Using Replication Manager message channels</a> for more
information).
</p>
<p>
In a Base API application, there is no way to
distinguish Berkeley DB messages from
application-specific messages, nor does Berkeley DB
offer any way to wrap application messages inside of
Berkeley DB messages. Distributed applications
exchanging their own messages should either enclose
Berkeley DB messages in their own wrappers, or use
separate network connections to send and receive
Berkeley DB messages. The one exception to this rule
is connection information for new sites; Berkeley DB
offers a simple method for sites joining replication
groups to send connection information to the other
database environments in the group (see <a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a> for more information).
</p>
</li>
<li>
<p>
<span class="bold"><strong>How should I build my <span class="bold"><strong>send</strong></span>
function?</strong></span>
</p>
<p>
This depends on the specifics of the application.
One common way is to write the <span class="bold"><strong>rec</strong></span>
and <span class="bold"><strong>control</strong></span> arguments' sizes and data to a
socket connected to each remote site. On a fast, local
area net, the simplest method is likely to be to
construct broadcast messages. Each Berkeley DB message
would be encapsulated inside an application specific
message, with header information specifying the
intended recipient(s) for the message. This will
likely require a global numbering scheme, however, as
the Berkeley DB library has to be able to send
specific log records to clients apart from the general
broadcast of new log records intended for all members
of a replication group.
</p>
</li>
<li>
<p>
<span class="bold"><strong>Does every one of my threads of
control on the master have to set up its own
connection to every client? And, does every one of
my threads of control on the client have to set up
its own connection to every master?</strong></span>
</p>
<p>
This is not always necessary. In the Berkeley DB
replication model, any thread of control which
modifies a database in the master environment must be
prepared to send a message to the client environments,
and any thread of control which delivers a message to
a client environment must be prepared to send a
message to the master. There are many ways in which
these requirements can be satisfied.
</p>
<p>
The simplest case is probably a single,
multithreaded process running on the master and
clients. The process running on the master would
require a single write connection to each client and a
single read connection from each client. A process
running on each client would require a single read
connection from the master and a single write
connection to the master. Threads running in these
processes on the master and clients would use the same
network connections to pass messages back and forth.
</p>
<p>
A common complication is when there are multiple
processes running on the master and clients. A
straight-forward solution is to increase the numbers
of connections on the master — each process
running on the master has its own write connection to
each client. However, this requires only one
additional connection for each possible client in the
master process. The master environment still requires
only a single read connection from each client (this
can be done by allocating a separate thread of control
which does nothing other than receive client messages
and forward them into the database). Similarly, each
client still only requires a single thread of control
that receives master messages and forwards them into
the database, and which also takes database messages
and forwards them back to the master. This model
requires the networking infrastructure support
many-to-one writers-to-readers, of course.
</p>
<p>
If the number of network connections is a problem
in the multiprocess model, and inter-process
communication on the system is inexpensive enough, an
alternative is have a single process which
communicates between the master and each client, and
whenever a process' <span class="bold"><strong>send</strong></span>
function is called, the process
passes the message to the communications process which
is responsible for forwarding the message to the
appropriate client. Alternatively, a broadcast
mechanism will simplify the entire networking
infrastructure, as processes will likely no longer
have to maintain their own specific network
connections.
</p>
</li>
</ol>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="rep.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="rep_ex.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Network partitions </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Ex_rep: a replication example</td>
</tr>
</table>
</div>
</body>
</html>
|
