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
|
<?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>Special considerations for two-site replication groups</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="repmgr_channels.html" title="Using Replication Manager message channels" />
<link rel="next" href="rep_partition.html" title="Network partitions" />
</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">Special considerations for two-site replication groups</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="repmgr_channels.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_partition.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_twosite"></a>Special considerations for two-site replication groups</h2>
</div>
</div>
</div>
<p>
One of the benefits of replication is that it helps your
application remain available for writes even when a site crashes.
Another benefit is the added durability achieved by storing multiple
copies of your application data at different sites. However, if
your replication group contains only two sites, you must prioritize
which of these benefits is more important to your
application.
</p>
<p>
A two-site replication group is particularly vulnerable to
duplicate masters if there is a loss of communication between the
sites. The original master continues to accept new transactions.
If the original client detects the loss of the master and elects
itself master, it also starts accepting new transactions. When
communications are restored, there are duplicate masters and one
site's new transactions will be rolled back.
</p>
<p>
If it is unacceptable to your application for any new transactions
to be rolled back, the alternative in a two-site replication group
is to require both sites to be present in order to elect a master.
This stops a client from electing itself master when it loses
contact with the master and prevents creation of parallel sets of
transactions, one of which must be rolled back.
</p>
<p>
However, requiring both sites to be present to elect a master
results in a loss of write availability when the master crashes.
The client cannot take over as master and the replication group
exists in a read-only state until the original master site rejoins
the replication group.
</p>
<p>
Replication Manager applications use the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method
<a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag to make this tradeoff between
write availability and transaction durability. When this flag is
turned on, Replication Manager favors transaction durability. When
it is turned off, Replication Manager favors write
availability.
</p>
<p>
A two-site Replication Manager application that uses heartbeats in
an environment with frequent communications disruptions generally
should operate with the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag turned
on. Otherwise, frequent heartbeat failures will cause frequent
duplicate masters and the resulting elections and client
synchronizations will make one or both sites unavailable for
extended periods of time.
</p>
<p>
Base API applications use the values of the
<span class="bold"><strong>nvotes</strong></span> and
<span class="bold"><strong>nsites</strong></span> parameters in calls to the
<a href="../api_reference/C/repelect.html" class="olink">DB_ENV->rep_elect()</a> method to make this tradeoff. For more information, see
<a class="xref" href="rep_elect.html" title="Elections">Elections</a>.</p>
<p>
A replication group containing only two electable sites is subject
to duplicate masters and rollback of one site's new transactions
even when it contains additional unelectable sites. The
<a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> does not apply in this case because
the replication group is larger than two sites.
</p>
<p>
If both write availability and transaction durability are important
to your application, you should strongly consider having three or
more electable sites in your replication group. You should also
carefully choose an acknowledgement policy that requires at least a
quorum of sites. It is best to have an odd number of electable
sites to provide a clear majority in the event of a network
partition.
</p>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="repmgr_channels.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_partition.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Using Replication Manager message channels </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Network partitions</td>
</tr>
</table>
</div>
</body>
</html>
|
