Sindbad~EG File Manager
<?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 18.1.40</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 start up 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>
If a Replication Manager replication group contains only two
sites and one particular site should be master whenever
possible, the replication group can be configured to run in
preferred master mode. For more information, see
<a class="xref" href="rep_twosite.html#twosite_prefmas" title="Preferred master mode">Preferred master mode</a>.
</p>
<p>
Replication Manager applications may configure one or more
view sites. A view is a full or partial copy of the replicated
data that does not otherwise participate in the replication
group. For more information, see <a class="xref" href="rep_partview.html" title="Replication views">Replication views</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="comm_repsites.html#repmgr_channels" 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>
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists