<?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 class="navheader">
<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>
No, it does not.
In general this protocol is left entirely to the application.
Note, there is no reason not to use the communications channels
a Base API application 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. Replication Manager does not currently
offer this service to the application.
</p>
</li>
<li>
<p>
<span class="bold"><strong>Can I use replication to partition my
environment across multiple sites?</strong></span>
</p>
<p>
No, this is not possible. All replicated databases must be equally
shared by all environments in the replication group.
</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>
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>
