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_newsite.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/rep_newsite.html')
| -rw-r--r-- | docs/programmer_reference/rep_newsite.html | 82 |
1 files changed, 46 insertions, 36 deletions
diff --git a/docs/programmer_reference/rep_newsite.html b/docs/programmer_reference/rep_newsite.html index 072cc24f..d9360287 100644 --- a/docs/programmer_reference/rep_newsite.html +++ b/docs/programmer_reference/rep_newsite.html @@ -9,12 +9,12 @@ <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_comm.html" title="Building the communications infrastructure" /> - <link rel="next" href="group_membership.html" title="Managing Replication Manager Group Membership" /> + <link rel="next" href="group_membership.html" title="Managing Replication Manager group membership" /> </head> <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_comm.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="group_membership.html">Next</a></td> </tr> </table> @@ -38,36 +36,47 @@ </div> </div> </div> - <p>To add a new site to the replication group all that is needed -is for the client member to join. Berkeley DB will perform an -internal initialization from the master to the client automatically -and will run recovery on the client to bring it up to date -with the master.</p> - <p>For Base API applications, connecting to a -new site in the replication group happens whenever the -<a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method returns <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_NEWSITE" class="olink">DB_REP_NEWSITE</a>. The application -should assign the new site a local environment ID number, and all future -messages from the site passed to <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> should include that -environment ID number. It is possible, of course, for the application -to be aware of a new site before the return of <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> (for -example, applications using connection-oriented protocols are likely to -detect new sites immediately, while applications using broadcast -protocols may not).</p> - <p>Regardless, in applications supporting the dynamic addition of database -environments to replication groups, environments joining an existing -replication group may need to provide contact information. (For -example, in an application using TCP/IP sockets, a DNS name or IP -address might be a reasonable value to provide.) This can be done using -the <span class="bold"><strong>cdata</strong></span> parameter to the <a href="../api_reference/C/repstart.html" class="olink">DB_ENV->rep_start()</a> method. The information -referenced by <span class="bold"><strong>cdata</strong></span> is wrapped in the initial contact message -sent by the new environment, and is provided to the existing members of -the group using the <span class="bold"><strong>rec</strong></span> parameter returned by <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>. -If no additional information was provided for Berkeley DB to forward to the -existing members of the group, the <span class="bold"><strong>data</strong></span> field of the <span class="bold"><strong>rec</strong></span> -parameter passed to the <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method will be NULL after -<a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> returns <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_NEWSITE" class="olink">DB_REP_NEWSITE</a>.</p> - <p>Replication Manager automatically distributes contact information -using the mechanisms previously described.</p> + <p> + To add a new site to the replication group all that is + needed is for the client member to join. Berkeley DB will + perform an internal initialization from the master to the + client automatically and will run recovery on the client to + bring it up to date with the master. + </p> + <p> + For Base API applications, connecting to a new site in the + replication group happens whenever the <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method + returns <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_NEWSITE" class="olink">DB_REP_NEWSITE</a>. The application should assign the + new site a local environment ID number, and all future + messages from the site passed to <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> should include + that environment ID number. It is possible, of course, for the + application to be aware of a new site before the return of + <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> (for example, applications using + connection-oriented protocols are likely to detect new sites + immediately, while applications using broadcast protocols may + not). + </p> + <p> + Regardless, in applications supporting the dynamic addition + of database environments to replication groups, environments + joining an existing replication group may need to provide + contact information. (For example, in an application using + TCP/IP sockets, a DNS name or IP address might be a reasonable + value to provide.) This can be done using the <span class="bold"><strong>cdata</strong></span> parameter to the <a href="../api_reference/C/repstart.html" class="olink">DB_ENV->rep_start()</a> + method. The information referenced by <span class="bold"><strong>cdata</strong></span> + is wrapped in the initial contact + message sent by the new environment, and is provided to the + existing members of the group using the <span class="bold"><strong>rec</strong></span> + parameter returned by <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>. If no + additional information was provided for Berkeley DB to forward + to the existing members of the group, the <span class="bold"><strong>data</strong></span> field of the <span class="bold"><strong>rec</strong></span> parameter passed to the + <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method will be NULL after <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> returns + <a href="../api_reference/C/repmessage.html#repmsg_DB_REP_NEWSITE" class="olink">DB_REP_NEWSITE</a>. + </p> + <p> + Replication Manager automatically distributes contact + information using the mechanisms previously described. + </p> </div> <div class="navfooter"> <hr /> @@ -84,7 +93,8 @@ using the mechanisms previously described.</p> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Managing Replication Manager Group Membership</td> + <td width="40%" align="right" valign="top"> Managing Replication Manager + group membership</td> </tr> </table> </div> |