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.
A two-site replication group is particularly vulnerable to 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.
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.
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.
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.
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.
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.
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.
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.