diff options
Diffstat (limited to 'docs/programmer_reference/rep.html')
| -rw-r--r-- | docs/programmer_reference/rep.html | 273 |
1 files changed, 178 insertions, 95 deletions
diff --git a/docs/programmer_reference/rep.html b/docs/programmer_reference/rep.html index 15a7e5a4..6692e1fb 100644 --- a/docs/programmer_reference/rep.html +++ b/docs/programmer_reference/rep.html @@ -14,13 +14,11 @@ <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> - <th colspan="3" align="center">Chapter 12. - Berkeley DB Replication - </th> + <th colspan="3" align="center">Chapter 12. Berkeley DB Replication </th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="transapp_faq.html">Prev</a> </td> @@ -34,9 +32,7 @@ <div class="titlepage"> <div> <div> - <h2 class="title"><a id="rep"></a>Chapter 12. - Berkeley DB Replication - </h2> + <h2 class="title"><a id="rep"></a>Chapter 12. Berkeley DB Replication </h2> </div> </div> </div> @@ -72,7 +68,7 @@ </dt> <dt> <span class="sect1"> - <a href="rep_base_meth.html">Base API Methods</a> + <a href="rep_base_meth.html">Base API methods</a> </span> </dt> <dt> @@ -87,104 +83,132 @@ </dt> <dt> <span class="sect1"> - <a href="group_membership.html">Managing Replication Manager Group Membership</a> + <a href="group_membership.html">Managing Replication Manager + group membership</a> </span> </dt> <dd> <dl> <dt> <span class="sect2"> - <a href="group_membership.html#group_mem_add">Adding Sites to a Replication Group</a> + <a href="group_membership.html#group_mem_add">Adding sites to a replication + group</a> </span> </dt> <dt> <span class="sect2"> - <a href="group_membership.html#group_mem_remove">Removing Sites from a Replication Group</a> + <a href="group_membership.html#group_mem_remove">Removing sites from a + replication group</a> </span> </dt> <dt> <span class="sect2"> - <a href="group_membership.html#group_mem_primordialstartup">Primordial Startups</a> + <a href="group_membership.html#group_mem_primordialstartup">Primordial startups</a> </span> </dt> <dt> <span class="sect2"> - <a href="group_membership.html#group_mem_upgrade">Upgrading Groups</a> + <a href="group_membership.html#group_mem_upgrade">Upgrading groups</a> </span> </dt> </dl> </dd> <dt> <span class="sect1"> - <a href="rep_filename.html">Managing Replication Files</a> + <a href="rep_partview.html">Replication views</a> </span> </dt> <dt> <span class="sect1"> - <a href="rep_mgrmulti.html">Running Replication Manager in multiple processes</a> + <a href="rep_filename.html">Managing replication directories and files</a> </span> </dt> <dd> <dl> <dt> <span class="sect2"> - <a href="rep_mgrmulti.html#idp2239216">One replication process and multiple subordinate processes</a> + <a href="rep_filename.html#rep_dir">Replication database directory + considerations</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_mgrmulti.html#idp2202400">Persistence of local site network address configuration</a> + <a href="rep_filename.html#rep_files">Managing replication internal + files</a> + </span> + </dt> + </dl> + </dd> + <dt> + <span class="sect1"> + <a href="rep_mgrmulti.html">Running Replication Manager in + multiple processes</a> + </span> + </dt> + <dd> + <dl> + <dt> + <span class="sect2"> + <a href="rep_mgrmulti.html#idp1913552">One replication process and multiple subordinate + processes</a> + </span> + </dt> + <dt> + <span class="sect2"> + <a href="rep_mgrmulti.html#idp1910720">Persistence of local site network address + configuration</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_mgrmulti.html#idp2221464">Programming considerations</a> + <a href="rep_mgrmulti.html#idp1905672">Programming considerations</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_mgrmulti.html#idp2233184">Handling failure</a> + <a href="rep_mgrmulti.html#idp1902040">Handling failure</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_mgrmulti.html#idp2233360">Other miscellaneous rules</a> + <a href="rep_mgrmulti.html#idp1877896">Other miscellaneous rules</a> </span> </dt> </dl> </dd> <dt> <span class="sect1"> - <a href="rep_replicate.html">Running Replication using the db_replicate Utility</a> + <a href="rep_replicate.html">Running replication using the + db_replicate utility</a> </span> </dt> <dd> <dl> <dt> <span class="sect2"> - <a href="rep_replicate.html#idp2251336">One Replication Process and Multiple Subordinate Processes</a> + <a href="rep_replicate.html#idp1926936">One replication process and multiple subordinate processes</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_replicate.html#idp2268704">Common Use Case</a> + <a href="rep_replicate.html#idp1906152">Common use case</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_replicate.html#idp2278848">Avoiding Rollback</a> + <a href="rep_replicate.html#idp1939624">Avoiding rollback</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_replicate.html#idp2283896">When to Consider an Integrated HA Application</a> + <a href="rep_replicate.html#idp1937856">When to consider an integrated replication application</a> </span> </dt> </dl> </dd> <dt> <span class="sect1"> - <a href="rep_mgr_ack.html">Choosing a Replication Manager Ack Policy</a> + <a href="rep_mgr_ack.html">Choosing a Replication Manager acknowledgement policy</a> </span> </dt> <dt> @@ -194,7 +218,8 @@ </dt> <dt> <span class="sect1"> - <a href="rep_mastersync.html">Synchronizing with a master</a> + <a href="rep_mastersync.html">Synchronizing with a + master</a> </span> </dt> <dd> @@ -211,12 +236,12 @@ </dt> <dt> <span class="sect2"> - <a href="rep_mastersync.html#idp2309616">Blocked client operations</a> + <a href="rep_mastersync.html#idp1985136">Blocked client operations</a> </span> </dt> <dt> <span class="sect2"> - <a href="rep_mastersync.html#idp2331664">Clients too far out-of-date to synchronize</a> + <a href="rep_mastersync.html#idp2008240">Clients too far out-of-date to synchronize</a> </span> </dt> </dl> @@ -238,14 +263,15 @@ </dt> <dt> <span class="sect1"> - <a href="rep_lease.html">Master Leases</a> + <a href="rep_lease.html">Master leases</a> </span> </dt> <dd> <dl> <dt> <span class="sect2"> - <a href="rep_lease.html#masterlease_change_groupsize">Changing Group Size</a> + <a href="rep_lease.html#masterlease_change_groupsize">Changing group + size</a> </span> </dt> </dl> @@ -276,7 +302,7 @@ </dd> <dt> <span class="sect1"> - <a href="rep_clock_skew.html">Clock Skew</a> + <a href="rep_clock_skew.html">Clock skew</a> </span> </dt> <dt> @@ -308,6 +334,25 @@ <a href="rep_twosite.html">Special considerations for two-site replication groups</a> </span> </dt> + <dd> + <dl> + <dt> + <span class="sect2"> + <a href="rep_twosite.html#twosite_strict">Two-site strict configuration</a> + </span> + </dt> + <dt> + <span class="sect2"> + <a href="rep_twosite.html#twosite_prefmas">Preferred master mode</a> + </span> + </dt> + <dt> + <span class="sect2"> + <a href="rep_twosite.html#twosite_other">Other alternatives</a> + </span> + </dt> + </dl> + </dd> <dt> <span class="sect1"> <a href="rep_partition.html">Network partitions</a> @@ -330,13 +375,13 @@ </dt> <dt> <span class="sect1"> - <a href="rep_ex_rq.html">Ex_rep_base: putting it all together</a> + <a href="rep_ex_rq.html">Ex_rep_base: putting it all + together</a> </span> </dt> <dt> <span class="sect1"> - <a href="rep_ex_chan.html">Ex_rep_chan: a Replication Manager -channel example</a> + <a href="rep_ex_chan.html">Ex_rep_chan: a Replication Manager channel example</a> </span> </dt> </dl> @@ -349,71 +394,109 @@ channel example</a> </div> </div> </div> - <p>Berkeley DB includes support for building highly available applications based -on replication. Berkeley DB replication groups consist of some number of -independently configured database environments. There is a single -<span class="emphasis"><em>master</em></span> database environment and one or more <span class="emphasis"><em>client</em></span> -database environments. Master environments support both database reads -and writes; client environments support only database reads. If the -master environment fails, applications may upgrade a client to be the -new master. The database environments might be on separate computers, -on separate hardware partitions in a non-uniform memory access (NUMA) -system, or on separate disks in a single server. -As always with Berkeley DB environments, any number of -concurrent processes or threads may access a database environment. In -the case of a master environment, any number of threads of control may -read and write the environment, and in the case of a client environment, -any number of threads of control may read the environment.</p> - <p>Applications may be written to provide various degrees of consistency -between the master and clients. The system can be run synchronously -such that replicas are guaranteed to be up-to-date with all committed -transactions, but doing so may incur a significant performance penalty. -Higher performance solutions sacrifice total consistency, allowing the -clients to be out of date for an application-controlled amount of -time.</p> <p> - There are two ways to build replicated applications. The simpler way - is to use the Berkeley DB Replication Manager. The Replication Manager - provides a standard communications infrastructure, and it creates and - manages the background threads needed for processing replication - messages. -</p> - <p>The Replication Manager implementation is based on TCP/IP sockets, and -uses POSIX 1003.1 style networking and thread support. (On Windows -systems, it uses standard Windows thread support.) As a result, it is -not as portable as the rest of the Berkeley DB library itself.</p> - <p>The alternative is to use the lower-level replication "Base APIs". This -approach affords more flexibility, but requires the application to -provide some critical components:</p> + Berkeley DB includes support for building highly available + applications based on replication. Berkeley DB replication + groups consist of some number of independently configured + database environments. There is a single + <span class="emphasis"><em>master</em></span> database environment and one + or more <span class="emphasis"><em>client</em></span> database environments. + Master environments support both database reads and writes; + client environments support only database reads. If the master + environment fails, applications may upgrade a client to be the + new master. The database environments might be on separate + computers, on separate hardware partitions in a non-uniform + memory access (NUMA) system, or on separate disks in a single + server. As always with Berkeley DB environments, any number of + concurrent processes or threads may access a database + environment. In the case of a master environment, any number + of threads of control may read and write the environment, and + in the case of a client environment, any number of threads of + control may read the environment. + </p> + <p> + Applications may be written to provide various degrees of + consistency between the master and clients. The system can be + run synchronously such that replicas are guaranteed to be + up-to-date with all committed transactions, but doing so may + incur a significant performance penalty. Higher performance + solutions sacrifice total consistency, allowing the clients to + be out of date for an application-controlled amount of + time. + </p> + <p> + There are two ways to build replicated applications. The + simpler way is to use the Berkeley DB Replication Manager. The + Replication Manager provides a standard communications + infrastructure, and it creates and manages the background + threads needed for processing replication messages. + </p> + <p> + The Replication Manager implementation is based on TCP/IP + sockets, and uses POSIX 1003.1 style networking and thread + support. (On Windows systems, it uses standard Windows thread + support.) As a result, it is not as portable as the rest of + the Berkeley DB library itself. + </p> + <p> + The alternative is to use the lower-level replication "Base + APIs". This approach affords more flexibility, but requires + the application to provide some critical components: + </p> <div class="orderedlist"> <ol type="1"> - <li>A communication infrastructure. Applications may use whatever wire -protocol is appropriate for their application (for example, RPC, TCP/IP, -UDP, VI or message-passing over the backplane).</li> - <li>The application is responsible for naming. Berkeley DB refers to the members -of a replication group using an application-provided ID, and -applications must map that ID to a particular database environment or -communication channel.</li> - <li>The application is responsible for monitoring the status of the master -and clients, and identifying any unavailable database environments.</li> - <li>The application must provide whatever security policies are needed. -For example, the application may choose to encrypt data, use a secure -socket layer, or do nothing at all. The level of security is left to -the sole discretion of the application.</li> + <li> + A communication infrastructure. Applications may use + whatever wire protocol is appropriate for their + application (for example, RPC, TCP/IP, UDP, VI or + message-passing over the backplane). + </li> + <li> + The application is responsible for naming. Berkeley + DB refers to the members of a replication group using an + application-provided ID, and applications must map that ID + to a particular database environment or communication + channel. + </li> + <li> + The application is responsible for monitoring the + status of the master and clients, and identifying any + unavailable database environments. + </li> + <li> + The application must provide whatever security + policies are needed. For example, the application may + choose to encrypt data, use a secure socket layer, or do + nothing at all. The level of security is left to the sole + discretion of the application. + </li> </ol> </div> - <p>(Note that Replication Manager does not provide wire security for -replication messages.)</p> - <p>The following pages present various programming considerations, many of -which are directly relevant only for Base API applications. However, even when using Replication Manager it is -important to understand the concepts.</p> - <p>Finally, the Berkeley DB replication implementation has one other additional -feature to increase application reliability. Replication in Berkeley DB is -implemented to perform database updates using a different code path than -the standard ones. This means operations that manage to crash the -replication master due to a software bug will not necessarily also crash -replication clients.</p> - <p>For more information on the replication manager operations, see the <a href="../api_reference/C/rep.html#replist" class="olink">Replication and Related Methods</a> section in the <em class="citetitle">Berkeley DB C API Reference Guide.</em> </p> + <p> + (Note that Replication Manager does not provide wire + security for replication messages.) + </p> + <p> + The following pages present various programming + considerations, many of which are directly relevant only for + Base API applications. However, even when using Replication + Manager it is important to understand the concepts. + </p> + <p> + Finally, the Berkeley DB replication implementation has one + other additional feature to increase application reliability. + Replication in Berkeley DB is implemented to perform database + updates using a different code path than the standard ones. + This means operations that manage to crash the replication + master due to a software bug will not necessarily also crash + replication clients. + </p> + <p> + For more information on the Replication Manager operations, + see the <a href="../api_reference/C/rep.html#replist" class="olink">Replication + and Related Methods</a> section in the + <em class="citetitle">Berkeley DB C API Reference Guide.</em> + </p> </div> </div> <div class="navfooter"> |