Berkeley DB: DbEnv::rep_elect
Description: Berkeley DB: An embedded database programmatic toolkit.
Keywords: embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++

### DbEnv::rep_elect |

`

###

    #include <db_cxx.h>

    int
    DbEnv::rep_elect(int nsites, int nvotes, u_int32_t flags);

### Description: DbEnv::rep_elect

The DbEnv::rep_elect method holds an election for the master of a replication group.

The DbEnv::rep_elect method is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

If the election is successful, Berkeley DB will notify the application of the results of the election by means of either the DB_EVENT_REP_ELECTED or DB_EVENT_REP_NEWMASTER events (see DbEnv::set_event_notify method for more information). The application is responsible for adjusting its relationship to the other database environments in the replication group, including directing all database updates to the newly selected master, in accordance with the results of the election.

The thread of control that calls the DbEnv::rep_elect method must not be the thread of control that processes incoming messages; processing the incoming messages is necessary to successfully complete an election.

### Parameters

nsites
  The nsites parameter specifies the number of replication sites expected to participate in the election. Once the current site has election information from that many sites, it will short-circuit the election and immediately cast its vote for a new master. The nsites parameter must be a positive integer, no less than nvotes, or 0 if the election should use the value previously set using the DbEnv::rep_set_nsites method.
nvotes
  The nvotes parameter specifies the minimum number of replication sites from which the current site must have election information, before the current site will cast a vote for a new master. The nvotes parameter must be a positive integer and no greater than nsites, or 0 if the election should use the value ((nsites / 2) + 1) as the nvotes argument.
flags
  The flags parameter is currently unused, and must be set to 0.

Elections are done in two parts: first, replication sites collect information from the other replication sites they know about, and second, replication sites cast their votes for a new master. The second phase is triggered by one of two things: either the replication site gets election information from nsites sites, or the election timeout expires. Once the second phase is triggered, the replication site will cast a vote for the new master of its choice if, and only if, the site has election information from at least nvotes sites. If a site receives nvotes votes for it to become the new master, then it will become the new master.

We recommend nvotes be set to at least:

>     (sites participating in the election / 2) + 1

to ensure there are never more than two masters active at the same time even in the case of a network partition. When a network partitions, the side of the partition with more than half the environments will elect a new master and continue, while the environments communicating with fewer than half of the environments will fail to find a new master, as no site can get nvotes votes.

We recommend nsites be set to:

>     number of sites in the replication group - 1

when choosing a new master after a current master fails. This allows the group to reach a consensus without having to wait for the timeout to expire.

When choosing a master from among a group of client sites all restarting at the same time, it makes more sense to set nsites to the total number of sites in the group, since there is no known missing site. Furthermore, in order to ensure the best choice from among sites that may take longer to boot than the local site, setting nvotes also to this same total number of sites will guarantee that every site in the group is considered. Alternatively, using the special timeout for full elections allows full participation on restart but allows election of a master if one site does not reboot and rejoin the group in a reasonable amount of time. (See the Elections section in the Berkeley DB Reference Guide for more information.)

Setting nsites to lower values can increase the speed of an election, but can also result in election failure, and is usually not recommended.

### Errors

The DbEnv::rep_elect method may fail and throw DbException, encapsulating one of the following non-zero errors, or return one of the following non-zero errors:

DB_REP_UNAVAIL
  The replication group was unable to elect a master, or was unable to complete the election in the election timeout period (see DbEnv::rep_set_timeout method for more information).

### Class

DbEnv

### See Also

Replication and Related Methods`

Copyright (c) 1996,2007 Oracle. All rights reserved.