mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
122 lines
7.8 KiB
HTML
122 lines
7.8 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 Ack 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 11.2.5.2</p>
|
|||
|
|
</div>
|
|||
|
|
<table width="100%" summary="Navigation header">
|
|||
|
|
<tr>
|
|||
|
|
<th colspan="3" align="center">Choosing a Replication Manager Ack 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 Ack 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>
|
|||
|
|
</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>
|