mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
526 lines
19 KiB
HTML
526 lines
19 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 18.1.40</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_partview.html">Replication views</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="rep_filename.html">Managing replication directories and files</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<dl>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_filename.html#rep_dir">Replication database directory
|
||
considerations</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_filename.html#rep_files">Managing replication internal
|
||
files</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#idm140654537587456">One replication process and multiple subordinate
|
||
processes</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_mgrmulti.html#idm140654537551776">Persistence of local site network address
|
||
configuration</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_mgrmulti.html#idm140654537529360">Programming considerations</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_mgrmulti.html#idm140654537569984">Handling failure</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_mgrmulti.html#idm140654537528176">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#idm140654537518352">One replication process and multiple subordinate processes</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_replicate.html#idm140654537558288">Common use case</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_replicate.html#idm140654537514880">Avoiding rollback</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_replicate.html#idm140654537476528">When to consider an integrated replication application</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</dd>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="rep_mgr_ack.html">Choosing a Replication Manager acknowledgement 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#idm140654537427440">Blocked client operations</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="rep_mastersync.html#idm140654537395264">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="comm_repsites.html">Communicating between Replication Manager Sites</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<dl>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="comm_repsites.html#conf_writeforw">Configuring for Write Forwarding</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="comm_repsites.html#repmgr_channels">Using Replication Manager message channels</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</dd>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="rep_twosite.html">Special considerations for two-site replication groups</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<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>
|
||
</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 three 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>
|
||
For applications with simple data and transaction models,
|
||
Replication Manager provides automatic write forwarding as
|
||
a configurable option. Use of this option enables some
|
||
write operations to be performed on a client environment.
|
||
For more information, see
|
||
<a class="xref" href="comm_repsites.html" title="Communicating between Replication Manager Sites">Communicating between Replication Manager Sites</a>.
|
||
</p>
|
||
<p>
|
||
If for some reason using Replication Manager or write forwarding
|
||
does not meet your application's technical requirements, you will
|
||
have 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>
|