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_twosite.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/rep_twosite.html')
| -rw-r--r-- | docs/programmer_reference/rep_twosite.html | 285 |
1 files changed, 222 insertions, 63 deletions
diff --git a/docs/programmer_reference/rep_twosite.html b/docs/programmer_reference/rep_twosite.html index 550404bd..c8882906 100644 --- a/docs/programmer_reference/rep_twosite.html +++ b/docs/programmer_reference/rep_twosite.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="repmgr_channels.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_partition.html">Next</a></td> </tr> </table> @@ -38,78 +36,239 @@ </div> </div> </div> - <p> + <div class="toc"> + <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> + </div> + <p> One of the benefits of replication is that it helps your - application remain available for writes even when a site crashes. - Another benefit is the added durability achieved by storing multiple - copies of your application data at different sites. However, if - your replication group contains only two sites, you must prioritize - which of these benefits is more important to your - application. + application remain available for writes even when a site + crashes. Another benefit is the added durability achieved by + storing multiple copies of your application data at different + sites. However, if your replication group contains only two + sites, you must prioritize which of these benefits is more + important to your application. </p> - <p> + <p> A two-site replication group is particularly vulnerable to - duplicate masters if there is a loss of communication between the - sites. The original master continues to accept new transactions. - If the original client detects the loss of the master and elects - itself master, it also starts accepting new transactions. When - communications are restored, there are duplicate masters and one - site's new transactions will be rolled back. - </p> - <p> - If it is unacceptable to your application for any new transactions - to be rolled back, the alternative in a two-site replication group - is to require both sites to be present in order to elect a master. - This stops a client from electing itself master when it loses - contact with the master and prevents creation of parallel sets of - transactions, one of which must be rolled back. + duplicate masters when there is a disruption to communications + between the sites. The original master continues to accept new + transactions. If the original client detects the loss of the + master and elects itself master, it also starts accepting new + transactions. When communications are restored, there are + duplicate masters and one site's new transactions will be + rolled back. </p> <p> - However, requiring both sites to be present to elect a master - results in a loss of write availability when the master crashes. - The client cannot take over as master and the replication group - exists in a read-only state until the original master site rejoins - the replication group. + If it is unacceptable to your application for any new + transactions to be rolled back, the alternative in a two-site + replication group is to require both sites to be present in + order to elect a master. This stops a client from electing + itself master when it loses contact with the master and + prevents creation of parallel sets of transactions, one of + which must be rolled back. + However, requiring both sites to be present to elect a + master results in a loss of write availability when the master + crashes. The client cannot take over as master and the + replication group exists in a read-only state until the + original master site rejoins the replication group. </p> - <p> + <div class="sect2" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h3 class="title"><a id="twosite_strict"></a>Two-site strict configuration</h3> + </div> + </div> + </div> + <p> Replication Manager applications use the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method - <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag to make this tradeoff between - write availability and transaction durability. When this flag is - turned on, Replication Manager favors transaction durability. When - it is turned off, Replication Manager favors write - availability. + <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag to make this tradeoff + between write availability and transaction durability. When + this flag is turned on, Replication Manager favors transaction + durability. When it is turned off, Replication Manager favors + write availability. </p> - <p> - A two-site Replication Manager application that uses heartbeats in - an environment with frequent communications disruptions generally - should operate with the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag turned - on. Otherwise, frequent heartbeat failures will cause frequent - duplicate masters and the resulting elections and client + <p> + A two-site Replication Manager application that uses + heartbeats in an environment with frequent communications + disruptions generally should operate with the + <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag turned on. Otherwise, + frequent heartbeat failures will cause frequent duplicate + masters and the resulting elections and client synchronizations will make one or both sites unavailable for extended periods of time. </p> - <p> - Base API applications use the values of the - <span class="bold"><strong>nvotes</strong></span> and - <span class="bold"><strong>nsites</strong></span> parameters in calls to the - <a href="../api_reference/C/repelect.html" class="olink">DB_ENV->rep_elect()</a> method to make this tradeoff. For more information, see - <a class="xref" href="rep_elect.html" title="Elections">Elections</a>.</p> - <p> - A replication group containing only two electable sites is subject - to duplicate masters and rollback of one site's new transactions - even when it contains additional unelectable sites. The - <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> does not apply in this case because - the replication group is larger than two sites. + <p> + A replication group containing only two electable sites is + subject to duplicate masters and rollback of one site's new + transactions even when it contains additional unelectable + sites. The <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag does not apply in + this case because the replication group is larger than two + sites. </p> - <p> - If both write availability and transaction durability are important - to your application, you should strongly consider having three or - more electable sites in your replication group. You should also - carefully choose an acknowledgement policy that requires at least a - quorum of sites. It is best to have an odd number of electable - sites to provide a clear majority in the event of a network - partition. + <p> + Base API applications using two sites use the values of the <span class="bold"><strong>nvotes</strong></span> and <span class="bold"><strong>nsites</strong></span> parameters in calls to the <a href="../api_reference/C/repelect.html" class="olink">DB_ENV->rep_elect()</a> + method to make this durability vs. availability tradeoff. For more + information, see <a class="xref" href="rep_elect.html" title="Elections">Elections</a>. + </p> + </div> + <div class="sect2" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h3 class="title"><a id="twosite_prefmas"></a>Preferred master mode</h3> + </div> + </div> + </div> + <p> + In some two-site replication groups, it is desirable for one + particular site to function as the master whenever possible. This + might be due to hardware differences, geographical location, or + other reasons. Replication Manager preferred master mode provides + this behavior. + </p> + <p> + A preferred master replication group contains two sites where one + site is the <span class="bold"><strong>preferred master site</strong></span> + and the other site is the <span class="bold"><strong>client + site</strong></span>. The preferred master site operates as + the master as much of the time as its availability permits. + The client site takes over as <span class="bold"><strong>temporary + master</strong></span> when the preferred + master is unavailable, providing write availability when the + preferred master site is down. Transactions committed on the preferred + master site are never rolled back, providing more predictable + durability than turning off the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> flag. + </p> + <p> + In a preferred master replication group where the client site is + operating as the temporary master, when the preferred master site + again becomes available it synchronizes with the temporary master + and then automatically takes over as master. The preferred master + synchronization preserves temporary master transactions when + they do not conflict with any new preferred master transactions. If + there are conflicting transactions, the temporary master transactions + are always the transactions that are rolled back. + </p> + <p> + To configure a preferred master replication group, you use the + <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to specify the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_MASTER" class="olink">DB_REPMGR_CONF_PREFMAS_MASTER</a> + flag on the preferred master site and to specify the + <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_CLIENT" class="olink">DB_REPMGR_CONF_PREFMAS_CLIENT</a> flag on the client site. These + flags must be specified before calling the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method + and cannot be changed after it is called. Both sites should call + the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method using the <a href="../api_reference/C/repmgrstart.html#repmgrstart_DB_REP_CLIENT" class="olink">DB_REP_CLIENT</a> flags value. + </p> + <p> + Some configuration items are automatically set in preferred master + mode and cannot be changed: the <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_2SITE_STRICT" class="olink">DB_REPMGR_CONF_2SITE_STRICT</a> and + <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_ELECTIONS" class="olink">DB_REPMGR_CONF_ELECTIONS</a> flags are turned on, and + each site's priority value is set. The following timeout values + have different defaults in preferred master mode which can be + changed: <a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_HEARTBEAT_SEND" class="olink">DB_REP_HEARTBEAT_SEND</a>, <a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_HEARTBEAT_MONITOR" class="olink">DB_REP_HEARTBEAT_MONITOR</a>, + <a href="../api_reference/C/repset_timeout.html#set_timeout_DB_REP_ELECTION_RETRY" class="olink">DB_REP_ELECTION_RETRY</a>. Heartbeats cannot be turned off in + preferred master mode because they are required for automatic + takeovers. Preferred master mode + is not supported with master leases, in-memory databases, in-memory + logs, in-memory replication files or private environments. + </p> + <p> + When restarting a preferred master replication group after both + sites were down, it is best to restart the client site first in + order to preserve as many temporary master transactions as possible. + If the preferred master site is started first and then commits new + transactions, these new preferred master transactions would conflict + with any recent temporary master transactions and the temporary + master transactions would be rolled back. + </p> + <p> + If the preferred master site can no longer be used (for example, due + to a hardware failure), you can reconfigure the client site to become + the new preferred master site using the following steps: </p> + <div class="itemizedlist"> + <ul type="disc"> + <li> + <p> + Shut down the old preferred master site if it is still running. + Use the old client site (now operating as temporary master) to + remove the old preferred master site from the replication group, + then close the old client's environment. + </p> + </li> + <li> + <p> + If you are using the <a href="../api_reference/C/configuration_reference.html" class="olink">DB_CONFIG</a> file to configure preferred master + mode, edit it to replace the <a href="../api_reference/C/rep_set_config_parameter.html" class="olink">rep_set_config</a> method + <code class="literal">db_repmgr_conf_prefmas_client</code> parameter + with the <code class="literal">db_repmgr_conf_prefmas_master</code> + parameter and adjust any other configuration values as needed. + </p> + </li> + <li> + <p> + Perform a recovery on the new preferred master site's environment + and reopen it. + </p> + </li> + <li> + <p> + If you are using the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method to configure preferred + master mode, invoke it to configure the + <a href="../api_reference/C/repconfig.html#config_DB_REPMGR_CONF_PREFMAS_MASTER" class="olink">DB_REPMGR_CONF_PREFMAS_MASTER</a> flag and adjust any other + configuration values as needed. + </p> + </li> + <li> + <p> + Call the <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV->repmgr_start()</a> method with the <a href="../api_reference/C/repmgrstart.html#repmgrstart_DB_REP_CLIENT" class="olink">DB_REP_CLIENT</a> flags + value to restart this site as the new preferred master. + </p> + </li> + </ul> + </div> + <p> + Preferred master applications are more likely to have + <code class="literal">DB_LOCK_DEADLOCK</code>, + <code class="literal">DB_REP_HANDLE_DEAD</code> and <code class="literal">EACCES</code> + errors on either site during automatic takeovers and should be + prepared to handle these errors appropriately. + </p> + </div> + <div class="sect2" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h3 class="title"><a id="twosite_other"></a>Other alternatives</h3> + </div> + </div> + </div> + <p> + If both write availability and transaction durability are + important to your application, you should strongly consider + having three or more electable sites in your replication + group. You should also carefully choose an acknowledgement + policy that requires at least a quorum of sites. It is best to + have an odd number of electable sites to provide a clear + majority in the event of a network partition. + </p> + </div> </div> <div class="navfooter"> <hr /> |