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
|
<?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>Running Replication Manager in multiple processes</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_filename.html" title="Managing Replication Files" />
<link rel="next" href="rep_replicate.html" title="Running Replication using the db_replicate Utility" />
</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">Running Replication Manager in multiple processes</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="rep_filename.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_replicate.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_mgrmulti"></a>Running Replication Manager in multiple processes</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="rep_mgrmulti.html#idp52420616">One replication process and multiple subordinate processes</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="rep_mgrmulti.html#idp52417008">Persistence of local site network address configuration</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="rep_mgrmulti.html#idp52400144">Programming considerations</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="rep_mgrmulti.html#idp52414488">Handling failure</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="rep_mgrmulti.html#idp52412256">Other miscellaneous rules</a>
</span>
</dt>
</dl>
</div>
<p>Replication Manager supports shared access to a database environment
from multiple processes.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp52420616"></a>One replication process and multiple subordinate processes</h3>
</div>
</div>
</div>
<p>Each site in a replication group has just one network address (TCP/IP
host name and port number). This means that only one process can
accept incoming connections. At least one application process must
invoke the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method to initiate communications
and management of the replication state.</p>
<p>If it is convenient, multiple processes may issue calls to the
Replication Manager configuration methods, and multiple processes may
call <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>. Replication Manager automatically opens
the TCP/IP listening socket in the first process to do so (we'll call
it the "replication process" here), and ignores this step in any
subsequent processes ("subordinate processes").</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp52417008"></a>Persistence of local site network address configuration</h3>
</div>
</div>
</div>
<p>The local site network address is stored in shared memory,
and remains intact even when (all) processes close their environment
handles gracefully and terminate. A process which opens an
environment handle without running recovery automatically inherits the
existing local site network address configuration. Such a process may not
change the local site address (although it is allowed to redundantly
specify a local site configuration matching that which is already in
effect).</p>
<p>In order to change the local site network address, the application
must run recovery. The application can then specify a new local site
address before restarting Replication Manager. The application should also
remove the old local site address from the replication group if it is no
longer needed.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp52400144"></a>Programming considerations</h3>
</div>
</div>
</div>
<p>Note that Replication Manager applications must follow all the usual
rules for Berkeley DB multi-threaded and/or multi-process
applications, such as ensuring that the recovery operation occurs
single-threaded, only once, before any other thread or processes
operate in the environment.
Since Replication Manager creates its own background threads which
operate on the environment,
all environment handles must be opened with the <a href="../api_reference/C/dbopen.html#open_DB_THREAD" class="olink">DB_THREAD</a> flag, even
if the application is otherwise single-threaded per process.</p>
<p>At the replication master site, each Replication Manager process opens
outgoing TCP/IP connections to all clients in the replication group.
It uses these direct connections to send to clients any log records
resulting from update transactions that the process executes. But all
other replication activity —message processing, elections,
etc.— takes place only in the "replication process".</p>
<p>Replication Manager notifies the application of certain events, using
the callback function configured with the <a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV->set_event_notify()</a>
method. These notifications occur only in the process where the event
itself occurred. Generally this means that most notifications occur
only in the "replication process". Currently the only replication
notification that can occur in a "subordinate process" is
<a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a>.</p>
<p>It is not supported for a process running Replication Manager to
spawn a subprocess.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp52414488"></a>Handling failure</h3>
</div>
</div>
</div>
<p>Multi-process Replication Manager applications should handle failures
in a manner consistent with the rules described in
<a class="xref" href="transapp_fail.html" title="Handling failure in Transactional Data Store applications">Handling failure in Transactional Data Store applications</a>.
To summarize, there are
two ways to handle failure of a process:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>
The simple way is to kill all remaining processes, run
recovery, and then restart all processes from the beginning.
But this can be a bit drastic.
</p>
</li>
<li>
<p>
Using the <a href="../api_reference/C/envfailchk.html" class="olink">DB_ENV->failchk()</a> method, it is sometimes possible to
leave surviving processes running, and just restart the failed
process.
</p>
<p>
Multi-process Replication Manager applications using this
technique must start a new process when an old process fails.
It is not possible for a "subordinate process" to take over the
duties of a failed "replication process". If the failed
process happens to be the replication process, then after a
failchk() call the next process to call <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> will
become the new replication process.
</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp52412256"></a>Other miscellaneous rules</h3>
</div>
</div>
</div>
<div class="orderedlist">
<ol type="1">
<li>A database environment may not be shared between a Replication
Manager application process and a Base API application process.</li>
<li>It is not possible to run multiple Replication Manager processes
during mixed-version live upgrades from Berkeley DB versions prior
to 4.8.</li>
</ol>
</div>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="rep_filename.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_replicate.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Managing Replication Files </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Running Replication using the db_replicate Utility</td>
</tr>
</table>
</div>
</body>
</html>
|
