Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/rep_twosite.html | 285 ++++++++++++++++++++++------- 1 file changed, 222 insertions(+), 63 deletions(-) (limited to 'docs/programmer_reference/rep_twosite.html') 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 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 12. - Berkeley DB Replication -	Chapter 12. Berkeley DB Replication	Next

@@ -38,78 +36,239 @@

+ + Two-site strict configuration + +
+ + Preferred master mode + +
+ + Other alternatives + +

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.

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. -

- 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.

- 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.

Two-site strict configuration

Replication Manager applications use the DB_ENV->rep_set_config() method - DB_REPMGR_CONF_2SITE_STRICT 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. + DB_REPMGR_CONF_2SITE_STRICT 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 two-site Replication Manager application that uses heartbeats in - an environment with frequent communications disruptions generally - should operate with the DB_REPMGR_CONF_2SITE_STRICT flag turned - on. Otherwise, frequent heartbeat failures will cause frequent - duplicate masters and the resulting elections and client +

+ A two-site Replication Manager application that uses + heartbeats in an environment with frequent communications + disruptions generally should operate with the + DB_REPMGR_CONF_2SITE_STRICT 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.

- Base API applications use the values of the - nvotes and - nsites parameters in calls to the - DB_ENV->rep_elect() method to make this tradeoff. For more information, see - Elections.

- 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 - DB_REPMGR_CONF_2SITE_STRICT does not apply in this case because - the replication group is larger than two sites. +

+ 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 DB_REPMGR_CONF_2SITE_STRICT flag does not apply in + this case because the replication group is larger than two + sites.

- 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. +

+ Base API applications using two sites use the values of the nvotes and nsites parameters in calls to the DB_ENV->rep_elect() + method to make this durability vs. availability tradeoff. For more + information, see Elections. +

Preferred master mode

+ 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. +

+ A preferred master replication group contains two sites where one + site is the preferred master site + and the other site is the client + site. The preferred master site operates as + the master as much of the time as its availability permits. + The client site takes over as temporary + master 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 DB_REPMGR_CONF_2SITE_STRICT flag. +

+ 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. +

+ To configure a preferred master replication group, you use the + DB_ENV->rep_set_config() method to specify the DB_REPMGR_CONF_PREFMAS_MASTER + flag on the preferred master site and to specify the + DB_REPMGR_CONF_PREFMAS_CLIENT flag on the client site. These + flags must be specified before calling the DB_ENV->repmgr_start() method + and cannot be changed after it is called. Both sites should call + the DB_ENV->repmgr_start() method using the DB_REP_CLIENT flags value. +

+ Some configuration items are automatically set in preferred master + mode and cannot be changed: the DB_REPMGR_CONF_2SITE_STRICT and + DB_REPMGR_CONF_ELECTIONS 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: DB_REP_HEARTBEAT_SEND, DB_REP_HEARTBEAT_MONITOR, + DB_REP_ELECTION_RETRY. 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. +

+ 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. +

+ 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:

+
+ 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. +
+
+
+ If you are using the DB_CONFIG file to configure preferred master + mode, edit it to replace the rep_set_config method + db_repmgr_conf_prefmas_client parameter + with the db_repmgr_conf_prefmas_master + parameter and adjust any other configuration values as needed. +
+
+
+ Perform a recovery on the new preferred master site's environment + and reopen it. +
+
+
+ If you are using the DB_ENV->rep_set_config() method to configure preferred + master mode, invoke it to configure the + DB_REPMGR_CONF_PREFMAS_MASTER flag and adjust any other + configuration values as needed. +
+
+
+ Call the DB_ENV->repmgr_start() method with the DB_REP_CLIENT flags + value to restart this site as the new preferred master. +
+

+ Preferred master applications are more likely to have + DB_LOCK_DEADLOCK, + DB_REP_HANDLE_DEAD and EACCES + errors on either site during automatic takeovers and should be + prepared to handle these errors appropriately. +

Other alternatives

+ 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. +

-- cgit v1.2.1