mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 09:06:25 +00:00
203 lines
11 KiB
HTML
203 lines
11 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>Replication Manager methods</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_app.html" title="Building replicated applications" />
|
||
<link rel="next" href="rep_base_meth.html" title="Base API Methods" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Replication Manager methods</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="rep_app.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_base_meth.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_meth"></a>Replication Manager methods</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
Applications which use the Replication Manager support generally
|
||
call the following Berkeley DB methods. The general pattern is to
|
||
call various methods to configure Replication Manager, and then
|
||
start it by calling <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>. Once this initialization is
|
||
complete, the application rarely needs to call any of these
|
||
methods. (A prime example of an exception to this rule would be
|
||
the <a href="../api_reference/C/repsync.html" class="olink">DB_ENV->rep_sync()</a> method, if the application is
|
||
<a class="xref" href="rep_mastersync.html#rep_delay_sync" title="Delaying client synchronization">Delaying client synchronization</a>.)
|
||
</p>
|
||
<div class="variablelist">
|
||
<dl>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
The <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle is used to configure a site that
|
||
belongs to the replication group. You can obtain a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
|
||
handle by calling the <a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV->repmgr_site()</a> method. When you do this, you
|
||
provide the TCP/IP host name and port that the replication
|
||
site uses for incoming connections.
|
||
</p>
|
||
<p>
|
||
Once you have the <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle, you use the
|
||
<a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE->set_config()</a> method to configure the handle. One of
|
||
the things you can configure about the handle is whether it
|
||
is the local site (using the <code class="literal">DB_LOCAL_SITE</code>
|
||
parameter). You must configure one and only one <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle
|
||
to be a local site before you start replication.
|
||
</p>
|
||
<p>
|
||
You can also optionally configure <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handles for
|
||
remote sites to help Replication Manager startup more
|
||
efficiently. Note that it is usually not necessary for
|
||
each site in the replication group initially to know about
|
||
all other sites in the group. Sites can discover each
|
||
other dynamically, as described in
|
||
<a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a>.
|
||
</p>
|
||
<p>
|
||
Once you have configured your <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handles, you start
|
||
replication using <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>.
|
||
</p>
|
||
<p>
|
||
When you are shutting down your application, you must
|
||
use the <a href="../api_reference/C/dbsite_close.html" class="olink">DB_SITE->close()</a> method to close
|
||
all your open <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handles before you close your
|
||
environment handles.
|
||
</p>
|
||
</dd>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/repmgrset_ack_policy.html" class="olink">DB_ENV->repmgr_set_ack_policy()</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
The <a href="../api_reference/C/repmgrset_ack_policy.html" class="olink">DB_ENV->repmgr_set_ack_policy()</a> method configures the acknowledgement
|
||
policy to be used in the replication group, in other words, the
|
||
behavior of the master with respect to acknowledgements for
|
||
"permanent" messages, which implements the application's
|
||
requirements for <a class="xref" href="rep_trans.html" title="Transactional guarantees">Transactional guarantees</a>. The current implementation
|
||
requires all sites in the replication group to configure the same
|
||
acknowledgement policy.
|
||
</p>
|
||
</dd>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/reppriority.html" class="olink">DB_ENV->rep_set_priority()</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
The <a href="../api_reference/C/reppriority.html" class="olink">DB_ENV->rep_set_priority()</a> method configures the local site's priority
|
||
for the purpose of elections.
|
||
</p>
|
||
</dd>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/repset_timeout.html" class="olink">DB_ENV->rep_set_timeout()</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
This method optionally configures various timeout values.
|
||
Otherwise default timeout values as specified in <a href="../api_reference/C/repset_timeout.html" class="olink">DB_ENV->rep_set_timeout()</a>
|
||
are used. In particular, Replication Manager client sites can
|
||
be configured to monitor the health of the TCP/IP connection to
|
||
the master site using heartbeat messages. If the client
|
||
receives no messages from the master for a certain amount of
|
||
time, it considers the connection to be broken, and calls for
|
||
an election to choose a new master. Heartbeat messages
|
||
also help clients request missing master changes in the
|
||
absence of master activity.
|
||
</p>
|
||
</dd>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV->set_event_notify()</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
Once configured and started, Replication Manager does virtually
|
||
all of its work in the background, usually without the need for
|
||
any direct communication with the application. However,
|
||
occasionally events occur which the application may be
|
||
interested in knowing about. The application can request
|
||
notification of these events by calling the <a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV->set_event_notify()</a>
|
||
method.
|
||
</p>
|
||
</dd>
|
||
<dt>
|
||
<span class="term">
|
||
<a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
The <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method starts the replication system. It
|
||
opens the listening TCP/IP socket and creates all the
|
||
background processing threads that will be needed.
|
||
</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
<p>
|
||
In addition to the methods previously described, Replication Manager
|
||
applications may also call the following methods, as needed:
|
||
<a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a>, <a href="../api_reference/C/repset_limit.html" class="olink">DB_ENV->rep_set_limit()</a>, <a href="../api_reference/C/repset_request.html" class="olink">DB_ENV->rep_set_request()</a>, <a href="../api_reference/C/repsync.html" class="olink">DB_ENV->rep_sync()</a> and <a href="../api_reference/C/repstat.html" class="olink">DB_ENV->rep_stat()</a>.
|
||
</p>
|
||
<p>
|
||
Finally, Replication Manager applications can also make use of the
|
||
Replication Manager's message channels. This allows the various
|
||
sites in the replication group to pass messages that are tailored
|
||
to the application's requirements. For more information, see
|
||
<a class="xref" href="repmgr_channels.html" title="Using Replication Manager message channels">Using Replication Manager message channels</a>.
|
||
</p>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="rep_app.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_base_meth.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Building replicated applications </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Base API Methods</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|