mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-17 01:26:25 +00:00
428 lines
16 KiB
HTML
428 lines
16 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>Chapter 12. Berkeley DB Replication</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="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
|||
|
<link rel="prev" href="transapp_faq.html" title="Transaction FAQ" />
|
|||
|
<link rel="next" href="rep_id.html" title="Replication environment IDs" />
|
|||
|
</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">Chapter 12.
|
|||
|
Berkeley DB Replication
|
|||
|
</th>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="20%" align="left"><a accesskey="p" href="transapp_faq.html">Prev</a> </td>
|
|||
|
<th width="60%" align="center"> </th>
|
|||
|
<td width="20%" align="right"> <a accesskey="n" href="rep_id.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
<hr />
|
|||
|
</div>
|
|||
|
<div class="chapter" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h2 class="title"><a id="rep"></a>Chapter 12.
|
|||
|
Berkeley DB Replication
|
|||
|
</h2>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div class="toc">
|
|||
|
<p>
|
|||
|
<b>Table of Contents</b>
|
|||
|
</p>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep.html#rep_intro">Replication introduction</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_id.html">Replication environment IDs</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_pri.html">Replication environment priorities</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_app.html">Building replicated applications</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_mgr_meth.html">Replication Manager methods</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_base_meth.html">Base API Methods</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_comm.html">Building the communications infrastructure</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_newsite.html">Connecting to a new site</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="group_membership.html">Managing Replication Manager Group Membership</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="group_membership.html#group_mem_add">Adding Sites to a Replication Group</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="group_membership.html#group_mem_remove">Removing Sites from a Replication Group</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="group_membership.html#group_mem_primordialstartup">Primordial Startups</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="group_membership.html#group_mem_upgrade">Upgrading Groups</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_mgrmulti.html">Running Replication Manager in multiple processes</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mgrmulti.html#id3907047">One replication process and multiple subordinate processes</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mgrmulti.html#id3907280">Persistence of network address configuration</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mgrmulti.html#id3906990">Programming considerations</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mgrmulti.html#id3904808">Handling failure</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mgrmulti.html#id3907368">Other miscellaneous rules</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_replicate.html">Running Replication using the db_replicate Utility</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_replicate.html#id3907110">One Replication Process and Multiple Subordinate Processes</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_replicate.html#id3907230">Common Use Case</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_replicate.html#id3907805">Avoiding Rollback</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_replicate.html#id3907891">When to Consider an Integrated HA Application</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_mgr_ack.html">Choosing a Replication Manager Ack Policy</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_elect.html">Elections</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_mastersync.html">Synchronizing with a master</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mastersync.html#rep_delay_sync">Delaying client synchronization</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mastersync.html#rep_c2c_sync">Client-to-client synchronization</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mastersync.html#id3908299">Blocked client operations</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_mastersync.html#id3908639">Clients too far out-of-date to synchronize</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_init.html">Initializing a new site</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_bulk.html">Bulk transfer</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_trans.html">Transactional guarantees</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_lease.html">Master Leases</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_lease.html#masterlease_change_groupsize">Changing Group Size</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_ryw.html">Read your writes consistency</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_ryw.html#gettoken">Getting a token</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_ryw.html#tokenhandling">Token handling</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="rep_ryw.html#usingtoken">Using a token to check or wait for a transaction</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_clock_skew.html">Clock Skew</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="repmgr_channels.html">Using Replication Manager message channels</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dd>
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="repmgr_channels.html#dbchannel_class">DB_CHANNEL</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="repmgr_channels.html#dbchannel_send">Sending messages over a message channel</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="repmgr_channels.html#dbchannel_receive">Receiving messages</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</dd>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_partition.html">Network partitions</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_faq.html">Replication FAQ</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_ex.html">Ex_rep: a replication example</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_ex_comm.html">Ex_rep_base: a TCP/IP based communication infrastructure</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_ex_rq.html">Ex_rep_base: putting it all together</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect1">
|
|||
|
<a href="rep_ex_chan.html">Ex_rep_chan: a Replication Manager
|
|||
|
channel example</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</div>
|
|||
|
<div class="sect1" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h2 class="title" style="clear: both"><a id="rep_intro"></a>Replication introduction</h2>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>Berkeley DB includes support for building highly available applications based
|
|||
|
on replication. Berkeley DB replication groups consist of some number of
|
|||
|
independently configured database environments. There is a single
|
|||
|
<span class="emphasis"><em>master</em></span> database environment and one or more <span class="emphasis"><em>client</em></span>
|
|||
|
database environments. Master environments support both database reads
|
|||
|
and writes; client environments support only database reads. If the
|
|||
|
master environment fails, applications may upgrade a client to be the
|
|||
|
new master. The database environments might be on separate computers,
|
|||
|
on separate hardware partitions in a non-uniform memory access (NUMA)
|
|||
|
system, or on separate disks in a single server.
|
|||
|
As always with Berkeley DB environments, any number of
|
|||
|
concurrent processes or threads may access a database environment. In
|
|||
|
the case of a master environment, any number of threads of control may
|
|||
|
read and write the environment, and in the case of a client environment,
|
|||
|
any number of threads of control may read the environment.</p>
|
|||
|
<p>Applications may be written to provide various degrees of consistency
|
|||
|
between the master and clients. The system can be run synchronously
|
|||
|
such that replicas are guaranteed to be up-to-date with all committed
|
|||
|
transactions, but doing so may incur a significant performance penalty.
|
|||
|
Higher performance solutions sacrifice total consistency, allowing the
|
|||
|
clients to be out of date for an application-controlled amount of
|
|||
|
time.</p>
|
|||
|
<p>
|
|||
|
There are two ways to build replicated applications. The simpler way
|
|||
|
is to use the Berkeley DB Replication Manager. The Replication Manager
|
|||
|
provides a standard communications infrastructure, and it creates and
|
|||
|
manages the background threads needed for processing replication
|
|||
|
messages.
|
|||
|
</p>
|
|||
|
<p>The Replication Manager implementation is based on TCP/IP sockets, and
|
|||
|
uses POSIX 1003.1 style networking and thread support. (On Windows
|
|||
|
systems, it uses standard Windows thread support.) As a result, it is
|
|||
|
not as portable as the rest of the Berkeley DB library itself.</p>
|
|||
|
<p>The alternative is to use the lower-level replication "Base APIs". This
|
|||
|
approach affords more flexibility, but requires the application to
|
|||
|
provide some critical components:</p>
|
|||
|
<div class="orderedlist">
|
|||
|
<ol type="1">
|
|||
|
<li>A communication infrastructure. Applications may use whatever wire
|
|||
|
protocol is appropriate for their application (for example, RPC, TCP/IP,
|
|||
|
UDP, VI or message-passing over the backplane).</li>
|
|||
|
<li>The application is responsible for naming. Berkeley DB refers to the members
|
|||
|
of a replication group using an application-provided ID, and
|
|||
|
applications must map that ID to a particular database environment or
|
|||
|
communication channel.</li>
|
|||
|
<li>The application is responsible for monitoring the status of the master
|
|||
|
and clients, and identifying any unavailable database environments.</li>
|
|||
|
<li>The application must provide whatever security policies are needed.
|
|||
|
For example, the application may choose to encrypt data, use a secure
|
|||
|
socket layer, or do nothing at all. The level of security is left to
|
|||
|
the sole discretion of the application.</li>
|
|||
|
</ol>
|
|||
|
</div>
|
|||
|
<p>(Note that Replication Manager does not provide wire security for
|
|||
|
replication messages.)</p>
|
|||
|
<p>The following pages present various programming considerations, many of
|
|||
|
which are directly relevant only for Base API applications. However, even when using Replication Manager it is
|
|||
|
important to understand the concepts.</p>
|
|||
|
<p>Finally, the Berkeley DB replication implementation has one other additional
|
|||
|
feature to increase application reliability. Replication in Berkeley DB is
|
|||
|
implemented to perform database updates using a different code path than
|
|||
|
the standard ones. This means operations that manage to crash the
|
|||
|
replication master due to a software bug will not necessarily also crash
|
|||
|
replication clients.</p>
|
|||
|
<p>For more information on the replication manager operations, see the <a href="../api_reference/C/rep.html#replist" class="olink">Replication and Related Methods</a> section in the <em class="citetitle">Berkeley DB C API Reference Guide.</em> </p>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div class="navfooter">
|
|||
|
<hr />
|
|||
|
<table width="100%" summary="Navigation footer">
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left"><a accesskey="p" href="transapp_faq.html">Prev</a> </td>
|
|||
|
<td width="20%" align="center"> </td>
|
|||
|
<td width="40%" align="right"> <a accesskey="n" href="rep_id.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left" valign="top">Transaction FAQ </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right" valign="top"> Replication environment IDs</td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
</div>
|
|||
|
</body>
|
|||
|
</html>
|