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 FAQ</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_partition.html" title="Network partitions" />
<link rel="next" href="rep_ex.html" title="Ex_rep: a replication example" />
</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 FAQ</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="rep_partition.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_ex.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_faq"></a>Replication FAQ</h2>
</div>
</div>
</div>
<div class="orderedlist">
<ol type="1">
<li>
<p>
<span class="bold"><strong>Does Berkeley DB provide support
for forwarding write queries from clients to
masters?</strong></span>
</p>
<p>
Yes, for applications with simple data and transaction
models, Berkeley DB provides automatic write forwarding
as a configurable option. Use of this option enables some
write operations to be performed on a client environment.
</p>
<p>
In cases where a more complex data and transaction model
is used, this protocol is left entirely to the
application. In addition, an application can use
Replication Manager message channels to send its own messages
to other sites in the replication group using Replication
Manager's internal communications infrastructure.
See
<a class="xref" href="rep_ex_chan.html" title="Ex_rep_chan: a Replication Manager channel example">Ex_rep_chan: a Replication Manager channel example</a> for information
about a sample program that demonstrates this use of
message channels). For a Base API application, it is
possible to use the communications channels it
establishes for replication support to forward
database update messages to the master, since Berkeley
DB does not require those channels to be used
exclusively for replication messages.
</p>
</li>
<li>
<p>
<span class="bold"><strong>Can I use replication to
partition my environment across multiple
sites?</strong></span>
</p>
<p>
Yes, you can create partial views to accomplish
this. See <a class="xref" href="rep_partview.html" title="Replication views">Replication views</a> for more
information.
</p>
</li>
<li>
<p>
<span class="bold"><strong>I'm running with replication but
I don't see my databases on the client.</strong></span>
</p>
<p>
This problem may be the result of the application
using absolute path names for its databases, and the
pathnames are not valid on the client system.
</p>
</li>
<li>
<p>
<span class="bold"><strong>How can I distinguish Berkeley
DB messages from application messages?</strong></span>
</p>
<p>
Replication Manager provides its own communications
infrastructure for replication messages. You can
create message channels to pass application-specific
messages using this infrastructure (see <a class="xref" href="comm_repsites.html#repmgr_channels" title="Using Replication Manager message channels">Using Replication Manager message channels</a> for more
information).
</p>
<p>
In a Base API application, there is no way to
distinguish Berkeley DB messages from
application-specific messages, nor does Berkeley DB
offer any way to wrap application messages inside of
Berkeley DB messages. Distributed applications
exchanging their own messages should either enclose
Berkeley DB messages in their own wrappers, or use
separate network connections to send and receive
Berkeley DB messages. The one exception to this rule
is connection information for new sites; Berkeley DB
offers a simple method for sites joining replication
groups to send connection information to the other
database environments in the group (see <a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a> for more information).
</p>
</li>
<li>
<p>
<span class="bold"><strong>How should I build my <span class="bold"><strong>send</strong></span>
function?</strong></span>
</p>
<p>
This depends on the specifics of the application.
One common way is to write the <span class="bold"><strong>rec</strong></span>
and <span class="bold"><strong>control</strong></span> arguments' sizes and data to a
socket connected to each remote site. On a fast, local
area net, the simplest method is likely to be to
construct broadcast messages. Each Berkeley DB message
would be encapsulated inside an application specific
message, with header information specifying the
intended recipient(s) for the message. This will
likely require a global numbering scheme, however, as
the Berkeley DB library has to be able to send
specific log records to clients apart from the general
broadcast of new log records intended for all members
of a replication group.
</p>
</li>
<li>
<p>
<span class="bold"><strong>Does every one of my threads of
control on the master have to set up its own
connection to every client? And, does every one of
my threads of control on the client have to set up
its own connection to every master?</strong></span>
</p>
<p>
This is not always necessary. In the Berkeley DB
replication model, any thread of control which
modifies a database in the master environment must be
prepared to send a message to the client environments,
and any thread of control which delivers a message to
a client environment must be prepared to send a
message to the master. There are many ways in which
these requirements can be satisfied.
</p>
<p>
The simplest case is probably a single,
multithreaded process running on the master and
clients. The process running on the master would
require a single write connection to each client and a
single read connection from each client. A process
running on each client would require a single read
connection from the master and a single write
connection to the master. Threads running in these
processes on the master and clients would use the same
network connections to pass messages back and forth.
</p>
<p>
A common complication is when there are multiple
processes running on the master and clients. A
straight-forward solution is to increase the numbers
of connections on the master — each process
running on the master has its own write connection to
each client. However, this requires only one
additional connection for each possible client in the
master process. The master environment still requires
only a single read connection from each client (this
can be done by allocating a separate thread of control
which does nothing other than receive client messages
and forward them into the database). Similarly, each
client still only requires a single thread of control
that receives master messages and forwards them into
the database, and which also takes database messages
and forwards them back to the master. This model
requires the networking infrastructure support
many-to-one writers-to-readers, of course.
</p>
<p>
If the number of network connections is a problem
in the multiprocess model, and inter-process
communication on the system is inexpensive enough, an
alternative is have a single process which
communicates between the master and each client, and
whenever a process' <span class="bold"><strong>send</strong></span>
function is called, the process
passes the message to the communications process which
is responsible for forwarding the message to the
appropriate client. Alternatively, a broadcast
mechanism will simplify the entire networking
infrastructure, as processes will likely no longer
have to maintain their own specific network
connections.
</p>
</li>
</ol>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="rep_partition.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_ex.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Network partitions </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Ex_rep: a replication example</td>
</tr>
</table>
</div>
</body>
</html>
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists