mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
166 lines
10 KiB
HTML
166 lines
10 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>Choosing a Replication Manager acknowledgement policy</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_replicate.html" title="Running replication using the db_replicate utility" />
|
||
<link rel="next" href="rep_elect.html" title="Elections" />
|
||
</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">Choosing a Replication Manager acknowledgement policy</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="rep_replicate.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_elect.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_mgr_ack"></a>Choosing a Replication Manager acknowledgement policy</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
Replication Manager allows the user to choose from a variety
|
||
of acknowledgement policies. There are two characteristics
|
||
that should be considered when choosing the policy:
|
||
consistency and durability. Consistency means making sure some
|
||
number of clients have applied all available master
|
||
transactions. Durability, in this context, means only
|
||
indicating success only if enough clients have applied a
|
||
transaction. The issue of how many is enough depends on the
|
||
application's requirements and varies per acknowledgement
|
||
policy. For example, <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_QUORUM" class="olink">DB_REPMGR_ACKS_QUORUM</a> means the data
|
||
will survive a change in master or a network partition. In
|
||
most cases, the number of sites for consistency is equal to
|
||
the number of sites for durability. Replication Manager uses
|
||
the consistency value to decide whether or not to wait for
|
||
acknowledgements. Replication manager uses the durability
|
||
value to decide either the transaction was successfully
|
||
processed or that a <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a> event should be
|
||
generated.
|
||
</p>
|
||
<p>
|
||
Replication Manager also strives to give the application the
|
||
answer and return to the application as quickly as possible.
|
||
Therefore, if it knows that the number of sites connected is
|
||
insufficient to meet the consistency value, then it does not
|
||
wait for any acknowledgements and if it knows that the
|
||
durability value cannot be met, it returns
|
||
<a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a> immediately to the user.
|
||
</p>
|
||
<p>
|
||
With one exception, discussed below, all acknowledgement
|
||
policies combine the consistency and durability values. For
|
||
most policies the primary purpose is the durability of the
|
||
data. For example, the <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_QUORUM" class="olink">DB_REPMGR_ACKS_QUORUM</a> policy ensures
|
||
that, if successful, the transaction's data is safe in the
|
||
event of a network partition so that a majority of the sites
|
||
in the group have the data. The <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_NONE" class="olink">DB_REPMGR_ACKS_NONE</a> policy
|
||
does not consider either consistency or durability, and it is
|
||
very fast because it does not wait for any acknowledgements
|
||
and it does not ever trigger the <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a>
|
||
event. Other policies, <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL" class="olink">DB_REPMGR_ACKS_ALL</a> and
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL_PEERS" class="olink">DB_REPMGR_ACKS_ALL_PEERS</a>, have a primary purpose of
|
||
consistency. These two policies wait for acknowledgements from
|
||
all (or all electable) sites in the group.
|
||
</p>
|
||
<p>
|
||
In the face of failure, however, the <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL" class="olink">DB_REPMGR_ACKS_ALL</a>
|
||
and <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL_PEERS" class="olink">DB_REPMGR_ACKS_ALL_PEERS</a> policies can result in a
|
||
surprising lack of consistency due to the fact that
|
||
Replication Manager strives to give the answer back to the
|
||
application as fast as it can. So, for example, with
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL" class="olink">DB_REPMGR_ACKS_ALL</a>, and one site down, Replication Manager
|
||
knows that disconnected site can never acknowledge, so it
|
||
immediately triggers <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a>. An
|
||
unfortunate side effect of this policy is that existing,
|
||
running sites may fall further and further behind the master
|
||
if the master site is sending a fast, busy stream of
|
||
transactions and never waiting for any site to send an
|
||
acknowledgement. The master does not wait because the
|
||
consistency value cannot be met, and it does trigger the
|
||
<a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a> event because the durability value
|
||
cannot be met, but those actions now affect the consistency of
|
||
the other running sites.
|
||
</p>
|
||
<p>
|
||
In order to counteract this unfortunate side effect, the
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL_AVAILABLE" class="olink">DB_REPMGR_ACKS_ALL_AVAILABLE</a> acknowledgement policy focuses
|
||
on the consistency aspect, but also considers durability. This
|
||
policy uses all sites for consistency, and a quorum of sites
|
||
for its decision about durability. As long as there is a
|
||
non-zero number of client replicas to send to, the master will
|
||
wait for all available sites to acknowledge the transaction.
|
||
As long as any client site is connected, this policy will
|
||
prevent the master from racing ahead if one or more sites is
|
||
down. On the master, this policy will then consider the
|
||
transaction durable if the number of acknowledgements meets
|
||
quorum for the group.
|
||
</p>
|
||
<p>
|
||
The following acknowledgement policies determine durability
|
||
using acknowledgements from electable peers only:
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_QUORUM" class="olink">DB_REPMGR_ACKS_QUORUM</a>, <a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ONE_PEER" class="olink">DB_REPMGR_ACKS_ONE_PEER</a>,
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html#ackspolicy_DB_REPMGR_ACKS_ALL_PEERS" class="olink">DB_REPMGR_ACKS_ALL_PEERS</a>. An electable peer is a site where
|
||
the priority value is greater than zero. In replication groups
|
||
using these policies, an unelectable site does not send
|
||
acknowledgements and cannot contribute to transaction
|
||
durability.
|
||
</p>
|
||
<p>
|
||
If your application needs to associate a <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a>
|
||
event with the specific transaction and thread that caused it,
|
||
this can be done by using your platform's thread-specific data
|
||
facility. You can create a thread-specific data structure that
|
||
contains a durability indicator. You would set the durability
|
||
indicator in the <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a> portion of your event
|
||
notification callback function. You can then check and clear the
|
||
durability indicator after your transaction commit operation
|
||
completes. You must be careful to coordinate this approach across
|
||
all application threads performing transaction commits or checkpoints
|
||
because any of these threads can generate a <a href="../api_reference/C/envevent_notify.html#event_notify_DB_EVENT_REP_PERM_FAILED" class="olink">DB_EVENT_REP_PERM_FAILED</a>
|
||
event. The ex_rep_mgr sample application demonstrates one way to
|
||
implement this capability. See
|
||
<a class="xref" href="rep_ex.html" title="Ex_rep: a replication example">Ex_rep: a replication example</a> for more information.
|
||
</p>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="rep_replicate.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_elect.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Running replication using the
|
||
db_replicate utility </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Elections</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|