diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/rep_faq.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/rep_faq.html')
| -rw-r--r-- | docs/programmer_reference/rep_faq.html | 260 |
1 files changed, 143 insertions, 117 deletions
diff --git a/docs/programmer_reference/rep_faq.html b/docs/programmer_reference/rep_faq.html index 480a352b..898b0621 100644 --- a/docs/programmer_reference/rep_faq.html +++ b/docs/programmer_reference/rep_faq.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </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> + <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> @@ -42,136 +40,164 @@ <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> + <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. A Replication Manager application can use + message channels to implement this capability (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> - No, this is not possible. All replicated databases must be equally - shared by all environments in the replication group. - </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> + <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> + <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> + 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="repmgr_channels.html" 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> + <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> + <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> + 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> |