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
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
|
<?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>Managing Replication Manager group membership</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_newsite.html" title="Connecting to a new site" />
<link rel="next" href="rep_partview.html" title="Replication views" />
</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">Managing Replication Manager
group membership</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="rep_newsite.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_partview.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="group_membership"></a>Managing Replication Manager
group membership</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="group_membership.html#group_mem_add">Adding sites to a replication
group</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="group_membership.html#group_mem_remove">Removing sites from a
replication group</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="group_membership.html#group_mem_primordialstartup">Primordial startups</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="group_membership.html#group_mem_upgrade">Upgrading groups</a>
</span>
</dt>
</dl>
</div>
<p>
A replication group is a collection of two or more database
environments which are configured to replicate with one
another. When operating normally, a replication group consists
of a master site and one or more read-only sites.
</p>
<p>
For Replication Manager applications, the sites comprising
the replication group are recorded in an internal group
membership database, so even if a group member is not
available, it counts towards the group's total site count.
This matters for certain replication activities, such as
holding elections and acknowledging replication messages that
require some number of sites to participate in these
activities. Replicated applications will often require all
sites, or a majority of sites, to participate before the
activity can be completed.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
If you are configuring your application to keep
replication metadata in-memory by specifying the
<a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_INMEM" class="olink">DB_REP_CONF_INMEM</a> flag to the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method, then
the internal group membership database is not stored
persistently on disk. This severely limits Replication
Manager's ability to automatically manage group
membership. For more information, including some
work-arounds, see <a class="xref" href="rep_filename.html" title="Managing replication directories and files">Managing replication directories and files</a>.
</p>
</div>
<p>
Because Replication Manager tracks group members, there are
some administrative activities that you should know about when
using Berkeley DB replication.
</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="group_mem_add"></a>Adding sites to a replication
group</h3>
</div>
</div>
</div>
<p>
To add a site to a replication group, you merely start
up the site such that it knows where at least one site in
the group is located. The new site then joins the group.
When this happens, the new site is recorded in the group
membership database.
</p>
<p>
Note that when you are starting the very first site in
the group for the very first time (called <span class="emphasis"><em>the
primordial start up</em></span>), there are no other
existing sites to help the new site join the group. In
fact, a primordial start up actually creates the group.
For this reason, there are some slight differences on how
to perform a primordial start up. For a description of
this, see <a class="xref" href="group_membership.html#group_mem_primordialstartup" title="Primordial startups">Primordial startups</a>.
</p>
<p>
When you add a site to a replication group, you use the
following general procedure:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Make sure your replication group is operating
well enough that write activity can occur.
</p>
</li>
<li>
<p>
Create and open the environment such that it is
configured to use replication.
</p>
</li>
<li>
<p>
Use <a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV->repmgr_site()</a> to obtain a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle.
Configure this handle for the local site's host
and port information when you create the handle.
Then, use <a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE->set_config()</a> to indicate that
this is the local site by setting the
<code class="literal">DB_LOCAL_SITE</code> parameter.
</p>
</li>
<li>
<p>
Use <a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV->repmgr_site()</a> to obtain a second <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
handle. Configure this handle with the host and
port information for a site that already belongs
to the replication group. Then, use
<a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE->set_config()</a> to indicate this site is a
"helper" site by setting the
<code class="literal">DB_BOOTSTRAP_HELPER</code>
parameter. By configuring a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle in
this way, your new site will know how to contact
the replication group so that it can join the
group.
</p>
</li>
<li>
<p>
Start replication as normal by configuring an
acknowledgement policy, setting the site's
replication priority, and then calling
<a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>.
</p>
</li>
</ul>
</div>
<p>
Note that on subsequent start-ups of your replication
code, any helper site information you might provide is
ignored because the Replication Manager reads the group
membership database in order to obtain this information.
</p>
<p>
Also, be aware that if the new site cannot be added to
the group for some reason (because a master site is not
available, or because insufficient replicas are running to
acknowledge the new site), the attempt to start the new
site via <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> will fail and return
<code class="literal">DB_REP_UNAVAIL</code>. You can then pause
and retry the start up attempt until it completes
successfully.
</p>
<p>
You must use the exact same host string and port number
to refer to a given site throughout your application and
on each of its sites.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="group_mem_remove"></a>Removing sites from a
replication group</h3>
</div>
</div>
</div>
<p>
Elections and message acknowledgements require
knowledge of the total number of sites in the group. If a
site is shut down, or is otherwise unable to communicate
with the rest of the group, it still counts towards the
total number of sites in the group. In most cases, this is
the desirable behavior.
</p>
<p>
However, if you are shutting down a site permanently,
then you should remove that site from the group. You might
also want to remove a site from the group if you are
shutting it down temporarily, but nevertheless for a very
long period of time (days or weeks). In either case, you
remove a site from the group by:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Make sure your replication group is operating
well enough that write activity can occur.
</p>
</li>
<li>
<p>
On one of the sites in your replication group
(this does not have to be the master site), use
<a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV->repmgr_site()</a> to obtain a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle.
Configure this handle with the host and port
information of the site that you want to remove.
</p>
<p>
Note that this step can occur at any site
— including the site that you are removing
from the group.
</p>
</li>
<li>
<p>
Call the <a href="../api_reference/C/dbsite_remove.html" class="olink">DB_SITE->remove()</a> method. This removes
the identified site from the group membership
database. If this action is not performed on the
master site, the client sends a request to the
master to perform the operation and awaits
confirmation.
</p>
<p>
A client removing itself can close its database
environment any time after the DB_SITE->remove()
method returns. A site that has been removed by
another site can close its database environment
any time after the
<a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_LOCAL_SITE_REMOVED" class="olink">DB_EVENT_REP_LOCAL_SITE_REMOVED</a> event is fired.
</p>
</li>
</ul>
</div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
Upon completing the above procedure, DO NOT call
the <a href="../api_reference/C/dbsite_close.html" class="olink">DB_SITE->close()</a> method. After removing (or even
attempting to remove) a site from the group using a
<a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle, the handle must never be accessed
again.
</p>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="group_mem_primordialstartup"></a>Primordial startups</h3>
</div>
</div>
</div>
<p>
If you have never started a site in a replication group
before, then the group membership database does not exist.
In this situation, you must start an initial site and
declare it to be the group creator. This causes the site
to become the master, create the group membership
database, and create a replication group of size 1. After
that, subsequent sites can add themselves to the group as
described in <a class="xref" href="group_membership.html#group_mem_add" title="Adding sites to a replication group">Adding sites to a replication
group</a>.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
It is never incorrect to declare a site the group
creator. This is true even well-after the replication
group has been established. This is because group
creator information is ignored on any site start-up,
except for the primoridial start-up; that is, a
start-up where the group membership database does not
exist.
</p>
</div>
<p>
To declare a site as the group creator:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Create and open the environment such that it is
configured to use replication.
</p>
</li>
<li>
<p>
Use <a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV->repmgr_site()</a> to obtain a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle.
Configure this handle for the local site's host
and port information when you create the handle.
Then, use <a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE->set_config()</a> to indicate that
this is the group creator site by setting the
<code class="literal">DB_GROUP_CREATOR</code> parameter.
</p>
</li>
<li>
<p>
Start replication as normal by configuring
acknowledgement policies, setting replication
priorities for the site, and then calling
<a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>.
</p>
</li>
</ul>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="group_mem_upgrade"></a>Upgrading groups</h3>
</div>
</div>
</div>
<p>
Prior to the Berkeley DB 11.2.5.2 release, replication
group membership was managed differently than in the way
it is described in the previous sections. For this reason,
when you upgrade from older releases of Berkeley DB to
11.2.5.2 or later, the upgrade procedure is different than
when upgrading between other releases.
</p>
<p>
To perform an upgrade that takes you from the old way
of managing group membership to the new way of managing
group membership (pre-11.2.5.2 to 11.2.5.2 and later), do
the following:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Update your replication code to use the new
<a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle and related methods. Recompile and
thoroughly test your code to make sure it is
production-ready.
</p>
</li>
<li>
<p>
Do the following one production machine at a
time. Make sure to do this at the master site
LAST.
</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>
Shut down the old replication code.
</p>
</li>
<li>
<p>
Install the new replication code.
</p>
</li>
<li>
<p>
Configure a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle for the
local site. Use <a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE->set_config()</a> to
indicate that this is a legacy site by
setting the <code class="literal">DB_LEGACY</code>
parameter.
</p>
</li>
<li>
<p>
Configure a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle for
<span class="emphasis"><em>every other site</em></span>
in the replication group. Set the
<code class="literal">DB_LEGACY</code> parameter
for each of these handles.
</p>
<p>
Please pay careful attention to this
step. To repeat: a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle MUST be
configured for EVERY site in the
replication group.
</p>
</li>
<li>
<p>
Start replication. The site is upgraded
at this point.
</p>
</li>
</ol>
</div>
<p>
Once you have performed this procedure for each
production site, making sure to upgrade the master
only after every other site has been upgraded, you
are done upgrading your replicated application to
use the current group membership mechanism.
</p>
</li>
</ul>
</div>
<p>
On subsequent restarts of your replication code, you do
not need to specify the <code class="literal">DB_LEGACY</code>
parameter, nor do you need to identify all of the
replication group members. However, it is not an error if
you do specify this information on subsequent start ups.
</p>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="rep_newsite.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_partview.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Connecting to a new site </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Replication views</td>
</tr>
</table>
</div>
</body>
</html>
|
