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