← Back to branch summary

~ubuntu-branches/ubuntu/maverick/evolution-data-server/maverick-proposed

« back to all changes in this revision

Viewing changes to libdb/docs/ref/rep/faq.html

  • Committer: Bazaar Package Importer
  • Author(s): Didier Roche
  • Date: 2010-05-17 17:02:06 UTC
  • mfrom: (1.1.79 upstream) (1.6.12 experimental)
  • Revision ID: james.westby@ubuntu.com-20100517170206-4ufr52vwrhh26yh0
Tags: 2.30.1-1ubuntu1
https://launchpad.net/bugs/42199
https://launchpad.net/bugs/229669
https://launchpad.net/bugs/173703
https://launchpad.net/bugs/360344
https://launchpad.net/bugs/508494
* Merge from debian experimental. Remaining change:
  (LP: #42199, #229669, #173703, #360344, #508494)
  + debian/control:
    - add Vcs-Bzr tag
    - don't use libgnome
    - Use Breaks instead of Conflicts against evolution 2.25 and earlier.
  + debian/evolution-data-server.install,
    debian/patches/45_libcamel_providers_version.patch:
    - use the upstream versioning, not a Debian-specific one 
  + debian/libedata-book1.2-dev.install, debian/libebackend-1.2-dev.install,
    debian/libcamel1.2-dev.install, debian/libedataserverui1.2-dev.install:
    - install html documentation
  + debian/rules:
    - don't build documentation it's shipped with the tarball

Show diffs side-by-side

added added

removed removed

Lines of Context:
libdb/docs/ref/rep/faq.html
1
 
<!--$Id$-->
2
 
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
3
 
<!--All rights reserved.-->
4
 
<!--See the file LICENSE for redistribution information.-->
5
 
<html>
6
 
<head>
7
 
<title>Berkeley DB Reference Guide: Replication FAQ</title>
8
 
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
9
 
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
10
 
</head>
11
 
<body bgcolor=white>
12
 
<table width="100%"><tr valign=top>
13
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></h3></td>
14
 
<td align=right><a href="../../ref/rep/partition.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/ex.html"><img src="../../images/next.gif" alt="Next"></a>
15
 
</td></tr></table>
16
 
<p>
17
 
<h1 align=center>Replication FAQ</h1>
18
 
<p><ol>
19
 
<p><li><b>Does Berkeley DB provide support for forwarding write queries from
20
 
clients to masters?</b>
21
 
<p>No, it does not.  The Berkeley DB RPC server code could be modified to support
22
 
this functionality, but in general this protocol is left entirely to
23
 
the application.  Note, there is no reason not to use the communications
24
 
channels the application establishes for replication support to forward
25
 
database update messages to the master, Berkeley DB does not require that
26
 
those channels be used exclusively for replication messages.
27
 
<p><li><b>Can I use replication to partition my environment across
28
 
multiple sites?</b>
29
 
<p>No, this is not possible.  All replicated databases must be equally
30
 
shared by all environments in the replication group.
31
 
<p><li><b>How can I distinguish Berkeley DB messages from application messages?</b>
32
 
<p>There is no way to distinguish Berkeley DB messages from application-specific
33
 
messages, nor does Berkeley DB offer any way to wrap application messages
34
 
inside of Berkeley DB messages.  Distributed applications exchanging their
35
 
own messages should either enclose Berkeley DB messages in their own wrappers,
36
 
or use separate network connections to send and receive Berkeley DB messages.
37
 
The one exception to this rule is connection information for new sites;
38
 
Berkeley DB offers a simple method for sites joining replication groups to
39
 
send connection information to the other database environments in the
40
 
group (see <a href="../../ref/rep/newsite.html">Connecting to a new site</a>
41
 
for more information).
42
 
<p><li><b>How should I build my <b>send</b> function?</b>
43
 
<p>This depends on the specifics of the application.  One common way is to
44
 
write the <b>rec</b> and <b>control</b> arguments' sizes and data to
45
 
a socket connected to each remote site.  On a fast, local area net, the
46
 
simplest method is likely to be construct broadcast messages.  Each
47
 
Berkeley DB message would be encapsulated inside an application specific
48
 
message, with header information specifying the intended recipient(s)
49
 
for the message.  This will likely require a global numbering scheme,
50
 
however, as the Berkeley DB library has to be able to send specific log
51
 
records to clients apart from the general broadcast of new log records
52
 
intended for all members of a replication group.
53
 
<p><li><b>Does every one of my threads of control on the master have to
54
 
set up its own connection to every client?  And, does every one of my
55
 
threads of control on the client have to set up its own connection to
56
 
every master?</b>
57
 
<p>This is not always necessary.  In the Berkeley DB replication model, any
58
 
thread of control which modifies a database in the master environment
59
 
must be prepared to send a message to the client environments, and any
60
 
thread of control which delivers a message to a client environment must
61
 
be prepared to send a message to the master.  There are many ways in
62
 
which these requirements can be satisfied.
63
 
<p>The simplest case is probably a single, multithreaded process running
64
 
on the master and clients.  The process running on the master would
65
 
require a single write connection to each client and a single read
66
 
connection from each client.  A process running on each client would
67
 
require a single read connection from the master and a single write
68
 
connection to the master.  Threads running in these processes on the
69
 
master and clients would use the same network connections to pass
70
 
messages back and forth.
71
 
<p>A common complication is when there are multiple processes running on
72
 
the master and clients.  A straight-forward solution is to increase the
73
 
numbers of connections on the master -- each process running on the
74
 
master has its own write connection to each client.  However, this
75
 
requires only one additional connection for each possible client in the
76
 
master process.  The master environment still requires only a single
77
 
read connection from each client (this can be done by allocating a
78
 
separate thread of control which does nothing other than receive client
79
 
messages and forward them into the database).  Similarly, each client
80
 
still only requires a single thread of control that receives master
81
 
messages and forwards them into the database, and which also takes
82
 
database messages and forwards them back to the master.  This model
83
 
requires the networking infrastructure support many-to-one
84
 
writers-to-readers, of course.
85
 
<p>If the number of network connections is a problem in the multiprocess
86
 
model, and inter-process communication on the system is inexpensive
87
 
enough, an alternative is have a single process which communicates
88
 
between the master the each client, and whenever a process'
89
 
<b>send</b> function is called, the process passes the message to the
90
 
communications process which is responsible for forwarding the message
91
 
to the appropriate client.  Alternatively, a broadcast mechanism will
92
 
simplify the entire networking infrastructure, as processes will likely
93
 
no longer have to maintain their own specific network connections.
94
 
<p><li><b>Can I use replication to replicate just the database
95
 
environment's log files?</b>
96
 
<p>Yes.  If the <a href="../../api_c/rep_start.html#DB_REP_LOGSONLY">DB_REP_LOGSONLY</a> flag is specified to
97
 
<a href="../../api_c/rep_start.html">DB_ENV-&gt;rep_start</a>, the client site acts as a repository for logfiles
98
 
(see <a href="../../ref/rep/logonly.html">Log file only clients</a> for more
99
 
information).
100
 
</ol>
101
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/rep/partition.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/ex.html"><img src="../../images/next.gif" alt="Next"></a>
102
 
</td></tr></table>
103
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
104
 
</body>
105
 
</html>