mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
294 lines
15 KiB
HTML
294 lines
15 KiB
HTML
<?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="comm_repsites.html" title="Communicating between Replication Manager Sites" />
|
||
<link rel="next" href="rep_partition.html" title="Network partitions" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 18.1.40</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="comm_repsites.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>
|
||
<div class="toc">
|
||
<dl>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_twosite.html#twosite_strict">Two-site strict configuration</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_twosite.html#twosite_prefmas">Preferred master mode</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_twosite.html#twosite_other">Other alternatives</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</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 when there is a disruption to communications
|
||
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.
|
||
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>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="twosite_strict"></a>Two-site strict configuration</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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>
|
||
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> flag does not apply in
|
||
this case because the replication group is larger than two
|
||
sites.
|
||
</p>
|
||
<p>
|
||
Base API applications using two sites 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 durability vs. availability tradeoff. For more
|
||
information, see <a class="xref" href="rep_elect.html" title="Elections">Elections</a>.
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="twosite_prefmas"></a>Preferred master mode</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
In some two-site replication groups, it is desirable for one
|
||
particular site to function as the master whenever possible. This
|
||
might be due to hardware differences, geographical location, or
|
||
other reasons. Replication Manager preferred master mode provides
|
||
this behavior.
|
||
</p>
|
||
<p>
|
||
A preferred master replication group contains two sites where one
|
||
site is the <span class="bold"><strong>preferred master site</strong></span>
|
||
and the other site is the <span class="bold"><strong>client
|
||
site</strong></span>. The preferred master site operates as
|
||
the master as much of the time as its availability permits.
|
||
The client site takes over as <span class="bold"><strong>temporary
|
||
master</strong></span> when the preferred
|
||
master is unavailable, providing write availability when the
|
||
preferred master site is down. Transactions committed on the preferred
|
||
master site are never rolled back, providing more predictable
|
||
durability than turning off the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag.
|
||
</p>
|
||
<p>
|
||
In a preferred master replication group where the client site is
|
||
operating as the temporary master, when the preferred master site
|
||
again becomes available it synchronizes with the temporary master
|
||
and then automatically takes over as master. The preferred master
|
||
synchronization preserves temporary master transactions when
|
||
they do not conflict with any new preferred master transactions. If
|
||
there are conflicting transactions, the temporary master transactions
|
||
are always the transactions that are rolled back.
|
||
</p>
|
||
<p>
|
||
To configure a preferred master replication group, you use the
|
||
<a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to specify the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_MASTER" class="olink">DB_REPMGR_CONF_PREFMAS_MASTER</a>
|
||
flag on the preferred master site and to specify the
|
||
<a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_CLIENT" class="olink">DB_REPMGR_CONF_PREFMAS_CLIENT</a> flag on the client site. These
|
||
flags must be specified before calling the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method
|
||
and cannot be changed after it is called. Both sites should call
|
||
the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method using the <a href="../api_reference/C/repmgrstart.html#repmgrstart_DB_REP_CLIENT" class="olink">DB_REP_CLIENT</a> flags value.
|
||
</p>
|
||
<p>
|
||
Some configuration items are automatically set in preferred master
|
||
mode and cannot be changed: the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> and
|
||
<a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_ELECTIONS" class="olink">DB_REPMGR_CONF_ELECTIONS</a> flags are turned on, and
|
||
each site's priority value is set. The following timeout values
|
||
have different defaults in preferred master mode which can be
|
||
changed: <a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_HEARTBEAT_SEND" class="olink">DB_REP_HEARTBEAT_SEND</a>, <a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_HEARTBEAT_MONITOR" class="olink">DB_REP_HEARTBEAT_MONITOR</a>,
|
||
<a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_ELECTION_RETRY" class="olink">DB_REP_ELECTION_RETRY</a>. Heartbeats cannot be turned off in
|
||
preferred master mode because they are required for automatic
|
||
takeovers. Preferred master mode
|
||
is not supported with master leases, in-memory databases, in-memory
|
||
logs, in-memory replication files or private environments.
|
||
</p>
|
||
<p>
|
||
When restarting a preferred master replication group after both
|
||
sites were down, it is best to restart the client site first in
|
||
order to preserve as many temporary master transactions as possible.
|
||
If the preferred master site is started first and then commits new
|
||
transactions, these new preferred master transactions would conflict
|
||
with any recent temporary master transactions and the temporary
|
||
master transactions would be rolled back.
|
||
</p>
|
||
<p>
|
||
If the preferred master site can no longer be used (for example, due
|
||
to a hardware failure), you can reconfigure the client site to become
|
||
the new preferred master site using the following steps:
|
||
</p>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<p>
|
||
Shut down the old preferred master site if it is still running.
|
||
Use the old client site (now operating as temporary master) to
|
||
remove the old preferred master site from the replication group,
|
||
then close the old client's environment.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
If you are using the <a href="../api_reference/C/configuration_reference.html" class="olink">DB_CONFIG</a> file to configure preferred master
|
||
mode, edit it to replace the <a href="../api_reference/C/rep_set_config_parameter.html" class="olink">rep_set_config</a> method
|
||
<code class="literal">db_repmgr_conf_prefmas_client</code> parameter
|
||
with the <code class="literal">db_repmgr_conf_prefmas_master</code>
|
||
parameter and adjust any other configuration values as needed.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Perform a recovery on the new preferred master site's environment
|
||
and reopen it.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
If you are using the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to configure preferred
|
||
master mode, invoke it to configure the
|
||
<a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_MASTER" class="olink">DB_REPMGR_CONF_PREFMAS_MASTER</a> flag and adjust any other
|
||
configuration values as needed.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Call the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method with the <a href="../api_reference/C/repmgrstart.html#repmgrstart_DB_REP_CLIENT" class="olink">DB_REP_CLIENT</a> flags
|
||
value to restart this site as the new preferred master.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<p>
|
||
Preferred master applications are more likely to have
|
||
<code class="literal">DB_LOCK_DEADLOCK</code>,
|
||
<code class="literal">DB_REP_HANDLE_DEAD</code> and <code class="literal">EACCES</code>
|
||
errors on either site during automatic takeovers and should be
|
||
prepared to handle these errors appropriately.
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="twosite_other"></a>Other alternatives</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="comm_repsites.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">Communicating between Replication Manager Sites </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>
|