1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xmlns="http://www.w3.org/1999/xhtml"> 4 <head> 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 6 <title>Replication FAQ</title> 7 <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> 8 <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /> 9 <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" /> 10 <link rel="up" href="rep.html" title="Chapter��12.�� Berkeley DB Replication" /> 11 <link rel="prev" href="rep_partition.html" title="Network partitions" /> 12 <link rel="next" href="rep_ex.html" title="Ex_rep: a replication example" /> 13 </head> 14 <body> 15 <div class="navheader"> 16 <table width="100%" summary="Navigation header"> 17 <tr> 18 <th colspan="3" align="center">Replication FAQ</th> 19 </tr> 20 <tr> 21 <td width="20%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a>��</td> 22 <th width="60%" align="center">Chapter��12.�� 23 Berkeley DB Replication 24 </th> 25 <td width="20%" align="right">��<a accesskey="n" href="rep_ex.html">Next</a></td> 26 </tr> 27 </table> 28 <hr /> 29 </div> 30 <div class="sect1" lang="en" xml:lang="en"> 31 <div class="titlepage"> 32 <div> 33 <div> 34 <h2 class="title" style="clear: both"><a id="rep_faq"></a>Replication FAQ</h2> 35 </div> 36 </div> 37 </div> 38 <div class="orderedlist"> 39 <ol type="1"> 40 <li> 41 <p> 42 <span class="bold"><strong>Does Berkeley DB provide support for 43 forwarding write queries from clients to 44 masters?</strong></span> 45 </p> 46 <p> 47 No, it does not. 48 49 50 51 In general this protocol is left entirely to the application. 52 Note, there is no reason not to use the communications channels 53 a Base API application establishes for replication support to forward 54 database update messages to the master, since Berkeley DB does 55 not require those channels to be used exclusively for 56 replication messages. Replication Manager does not currently 57 offer this service to the application. 58 </p> 59 </li> 60 <li> 61 <p> 62 <span class="bold"><strong>Can I use replication to partition my 63 environment across multiple sites?</strong></span> 64 </p> 65 <p> 66 No, this is not possible. All replicated databases must be equally 67 shared by all environments in the replication group. 68 </p> 69 </li> 70 <li> 71 <p> 72 <span class="bold"><strong>I'm running with replication but I don't see my databases 73 on the client.</strong></span> 74 </p> 75 <p> 76 This problem may be the result of the application using absolute 77 path names for its databases, and the pathnames are not valid on 78 the client system. 79 </p> 80 </li> 81 <li> 82 <p> 83 <span class="bold"><strong>How can I distinguish Berkeley DB messages from application messages?</strong></span> 84 </p> 85 <p> 86 There is no way to distinguish Berkeley DB messages from 87 application-specific messages, nor does Berkeley DB offer any way 88 to wrap application messages inside of Berkeley DB messages. 89 Distributed applications exchanging their own messages should 90 either enclose Berkeley DB messages in their own wrappers, or use 91 separate network connections to send and receive Berkeley DB 92 messages. The one exception to this rule is connection information 93 for new sites; Berkeley DB offers a simple method for sites joining 94 replication groups to send connection information to the other 95 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). 96 </p> 97 </li> 98 <li> 99 <p> 100 <span class="bold"><strong>How should I build my <span class="bold"><strong>send</strong></span> function?</strong></span> 101 </p> 102 <p> 103 This depends on the specifics of the application. One common way 104 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 105 socket connected to each remote site. On a fast, local area net, 106 the simplest method is likely to be to construct broadcast 107 messages. Each Berkeley DB message would be encapsulated inside an 108 application specific message, with header information specifying 109 the intended recipient(s) for the message. This will likely 110 require a global numbering scheme, however, as the Berkeley DB 111 library has to be able to send specific log records to clients 112 apart from the general broadcast of new log records intended for 113 all members of a replication group. 114 </p> 115 </li> 116 <li> 117 <p> 118 <span class="bold"><strong>Does every one of my threads of control on 119 the master have to set up its own connection to every client? 120 And, does every one of my threads of control on the client have 121 to set up its own connection to every master?</strong></span> 122 </p> 123 <p> 124 This is not always necessary. In the Berkeley DB replication 125 model, any thread of control which modifies a database in the 126 master environment must be prepared to send a message to the client 127 environments, and any thread of control which delivers a message to 128 a client environment must be prepared to send a message to the 129 master. There are many ways in which these requirements can be 130 satisfied. 131 </p> 132 <p> 133 The simplest case is probably a single, multithreaded process 134 running on the master and clients. The process running on the 135 master would require a single write connection to each client and a 136 single read connection from each client. A process running on each 137 client would require a single read connection from the master and a 138 single write connection to the master. Threads running in these 139 processes on the master and clients would use the same network 140 connections to pass messages back and forth. 141 </p> 142 <p> 143 A common complication is when there are multiple processes running 144 on the master and clients. A straight-forward solution is to 145 increase the numbers of connections on the master ��� each 146 process running on the master has its own write connection to each 147 client. However, this requires only one additional connection for 148 each possible client in the master process. The master environment 149 still requires only a single read connection from each client (this 150 can be done by allocating a separate thread of control which does 151 nothing other than receive client messages and forward them into 152 the database). Similarly, each client still only requires a single 153 thread of control that receives master messages and forwards them 154 into the database, and which also takes database messages and 155 forwards them back to the master. This model requires the 156 networking infrastructure support many-to-one writers-to-readers, 157 of course. 158 </p> 159 <p> 160 If the number of network connections is a problem in the 161 multiprocess model, and inter-process communication on the system 162 is inexpensive enough, an alternative is have a single process 163 which communicates between the master and each client, and whenever 164 a process' <span class="bold"><strong>send</strong></span> function is 165 called, the process passes the message to the communications 166 process which is responsible for forwarding the message to the 167 appropriate client. Alternatively, a broadcast mechanism will 168 simplify the entire networking infrastructure, as processes will 169 likely no longer have to maintain their own specific network 170 connections. 171 </p> 172 </li> 173 </ol> 174 </div> 175 </div> 176 <div class="navfooter"> 177 <hr /> 178 <table width="100%" summary="Navigation footer"> 179 <tr> 180 <td width="40%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a>��</td> 181 <td width="20%" align="center"> 182 <a accesskey="u" href="rep.html">Up</a> 183 </td> 184 <td width="40%" align="right">��<a accesskey="n" href="rep_ex.html">Next</a></td> 185 </tr> 186 <tr> 187 <td width="40%" align="left" valign="top">Network partitions��</td> 188 <td width="20%" align="center"> 189 <a accesskey="h" href="index.html">Home</a> 190 </td> 191 <td width="40%" align="right" valign="top">��Ex_rep: a replication example</td> 192 </tr> 193 </table> 194 </div> 195 </body> 196</html> 197