mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
235 lines
12 KiB
HTML
235 lines
12 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 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>
|