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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
|
<?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>Chapter 1. Introduction</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="index.html" title="Getting Started with Replicated Berkeley DB Applications" />
<link rel="prev" href="moreinfo.html" title="For More Information" />
<link rel="next" href="repadvantage.html" title="Replication Benefits" />
</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">Chapter 1. Introduction</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="moreinfo.html">Prev</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="repadvantage.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2>
</div>
</div>
</div>
<div class="toc">
<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>
<span class="sect1">
<a href="introduction.html#overview">Overview</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="sect2">
<a href="introduction.html#repenvirons">Replication Environments</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#repdbs">Replication Databases</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#commlayer">Communications Layer</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#masterselect">Selecting a Master</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="sect1">
<a href="repadvantage.html">Replication Benefits</a>
</span>
</dt>
<dt>
<span class="sect1">
<a href="apioverview.html">The Replication APIs</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="sect2">
<a href="apioverview.html#repframeworkoverview">Replication Manager Overview</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="apioverview.html#repapioverview">Replication Base API Overview</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="sect1">
<a href="elections.html">Holding Elections</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="sect2">
<a href="elections.html#influencingelections">Influencing Elections</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="elections.html#winningelections">Winning Elections</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="elections.html#switchingmasters">Switching Masters</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="sect1">
<a href="permmessages.html">Permanent Message Handling</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="sect2">
<a href="permmessages.html#permmessagenot">When Not to Manage
Permanent Messages</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="permmessages.html#permmanage">Managing Permanent Messages</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="permmessages.html#permimplement">Implementing Permanent
Message Handling</a>
</span>
</dt>
</dl>
</dd>
</dl>
</div>
<p>
This book provides a thorough introduction and discussion on
replication as used with Berkeley DB (DB). It begins by offering a
general overview to replication and the benefits it provides. It also
describes the APIs that you use to implement replication, and it
describes architecturally the things that you need to do to your
application code in order to use the replication APIs. Finally, it
discusses the differences in backup and restore strategies that you
might pursue when using replication, especially where it comes to log
file removal.
</p>
<p>
You should understand the concepts from the
<span>
<em class="citetitle">Berkeley DB Getting Started with Transaction Processing</em>
</span>
guide before reading this book.
</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="overview"></a>Overview</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="introduction.html#repenvirons">Replication Environments</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#repdbs">Replication Databases</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#commlayer">Communications Layer</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="introduction.html#masterselect">Selecting a Master</a>
</span>
</dt>
</dl>
</div>
<p>
The DB replication APIs allow you to distribute your database
write operations (performed on a read-write master) to one or
more read-only <span class="emphasis"><em>replicas</em></span>.
For this reason, DB's replication implementation is said to be a
<span class="emphasis"><em>single master, multiple replica</em></span> replication strategy.
</p>
<p>
Note that your database write operations can occur only on the
master; any attempt to write to a replica results in an error
being
<span>raised by</span>
the DB API used to perform the write.
</p>
<p>
A single replication master and all of its replicas are referred
to as a <span class="emphasis"><em>replication group</em></span>. While all
members of the replication group can reside on the same
machine, usually each replication participant is placed on a
separate physical machine somewhere on the network.
</p>
<p>
Note that all replication applications must first be
transactional applications. The data that the master transmits
to its replicas are log records that are generated as records are
updated. Upon transactional commit, the master transmits a
transaction record which tells the replicas to commit the
records they previously received from the master. In order for
all of this to work, your replicated application must also be a
transactional application. For this reason, it is
recommended that you write and debug your DB application as
a stand-alone transactional application before introducing the
replication layer to your code.
</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="repenvirons"></a>Replication Environments</h3>
</div>
</div>
</div>
<p>
The most important requirement for a replication
participant is that it must use a unique Berkeley DB database
environment independent of all other replication
participants. So while multiple replication participants
can reside on the same physical machine, no two such participants
can share the same environment home directory.
</p>
<p>
For this reason, technically replication occurs between
unique <span class="emphasis"><em>database environments</em></span>. So in the strictest sense,
a replication group consists of a <span class="emphasis"><em>master
environment</em></span> and
one or more <span class="emphasis"><em>replica environments</em></span>. However, the reality
is that for production code, each such environment will
usually be located on its own unique machine. Consequently,
this manual sometimes talks about <span class="emphasis"><em>replication sites</em></span>, meaning the
unique combination of environment home directory, host and port that a specific
replication application is using.
</p>
<p>
There is no DB-specified limit to the number of
environments which can participate in a replication group.
The only limitation here is one of resources —
network bandwidth, for example.
</p>
<p>
(Note, however, that the Replication Manager does place a limit on the
number of environments you can use. See
<a class="xref" href="apioverview.html#repframeworkoverview" title="Replication Manager Overview">Replication Manager Overview</a>
for details.)
</p>
<p>
Also, DB's replication implementation requires all
participating environments to be assigned IDs that are
locally unique to the given environment. Depending on the
replication APIs that you choose to use, you may or may not
need to manage this particular detail.
</p>
<p>
For detailed information on database environments, see
the <em class="citetitle">Berkeley DB Getting Started with Transaction Processing</em>
guide. For more information on environment IDs, see
the <em class="citetitle">Berkeley DB Programmer's Reference Guide</em>.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="repdbs"></a>Replication Databases</h3>
</div>
</div>
</div>
<p>
DB's databases are managed and used in exactly the same way
as if you were writing a non-replicated application, with
a couple of caveats. First, the databases maintained in a replicated environment
must reside either in the <code class="literal">ENV_HOME</code>
directory, or in the directory identified by the
<code class="methodname">EnvironmentConfig.addDataDir()</code>
method. Unlike non-replication applications, you cannot place your
databases in a subdirectory below these locations. You should
also not use full path names for your databases or
environments as these are likely to break when they are replicated
to other machines.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="commlayer"></a>Communications Layer</h3>
</div>
</div>
</div>
<p>
In order to transmit database writes to the replication
replicas, DB requires a communications layer.
DB is agnostic as to what this layer should
look like. The only requirement is that it
be capable of passing two opaque data objects and an
environment ID from the master to its replicas without
corruption.
</p>
<p>
Because replicas are usually placed on different machines on
the network, the communications layer is usually some kind
of a network-aware implementation. Beyond that, its
implementation details are largely up to you. It could use
TCP/IP sockets, for example, or it could use
raw sockets if they perform better for your particular
application.
</p>
<p>
Note that you may not have to write your own communications
layer. DB provides a Replication Manager that
includes a fully-functional TCP/IP-based communications layer.
See <a class="xref" href="apioverview.html" title="The Replication APIs">The Replication APIs</a>
for more information.
</p>
<p>
See the <em class="citetitle">Berkeley DB Programmer's Reference Guide</em>
for a description of how to
write your own custom replication communications layer.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="masterselect"></a>Selecting a Master</h3>
</div>
</div>
</div>
<p>
Every replication group is allowed one and only one
master environment. Usually masters are selected by
holding an <span class="emphasis"><em>election</em></span>, although it
is possible to turn elections off and manually select
masters (this is not recommended for most replicated
applications).
</p>
<p>
When elections are being used, they are performed by the
underlying Berkeley DB replication code so you have to
do very little to implement them.
</p>
<p>
When holding an election, replicas "vote" on who should
be the master. Among replicas participating in the
election, the one with the most up-to-date set of log
records will win the election. Note that it's possible
for there to be a tie. When this occurs, priorities are
used to select the master. See
<a class="xref" href="elections.html" title="Holding Elections">Holding Elections</a>
for details.
</p>
<p>
For more information on holding and managing elections,
see <a class="xref" href="elections.html" title="Holding Elections">Holding Elections</a>.
</p>
</div>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="moreinfo.html">Prev</a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="repadvantage.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">For More Information </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Replication Benefits</td>
</tr>
</table>
</div>
</body>
</html>
|
