Library Version 18.1.40

Group Membership in Repmgr
Prev | Chapter 13. Upgrading Berkeley DB 11.2.5.1 applications to Berkeley DB 11.2.5.2 | Next

## Group Membership in Repmgr

Replication Manager now manages group membership much more closely, making it much easier for applications to add and remove sites from a replication group without risk of transaction loss. In order to accomplish this, the API for configuring group membership has changed significantly. The `repmgr_set_local_site()` and `repmgr_add_remote_site()` methods no longer exist; they are replaced by a new handle type, `DB_SITE`. The `repmgr_get_local_site()` method has been replaced by DB_ENV->repmgr_site(), which now returns a `DB_SITE` handle instead of a raw host/port network address.

Replication Manager applications may no longer call the DB_ENV->rep_set_nsites() method, because the Replication Manager now tracks the number of sites in the replication group for you. Replication Manager applications may still call DB_ENV->rep_get_nsites(), but only after a successful call to DB_ENV->repmgr_start().

For applications using the replication Base API there is no change, except that they may now call DB_ENV->rep_set_nsites() to change the group size even when Master Leases are in use.

The new Replication Manager group membership functionality is described in the Managing Replication Manager Group Membership chapter in the Berkeley DB Programmer's Reference Guide.

Replication Manager no longer prints an error message on a connection failure. Instead it generates an event with the equivalent information (invoking the application's event-handling call-back function).

### Upgrading

An existing application running a previous version of BDB can do a "live upgrade" so that only one site at a time has to be shut down. To do this, restart each site in the group, with the old master being shutdown last. When each site is restarted, use `DB_SITE` to configure the local site with the flag `DB_LEGACY`, and create a `DB_SITE` handle with a full specification of all the remote site addresses for all other sites currently in the group, and configure each handle with the `DB_LEGACY` flag. When the old master is restarted and a new master has been established, the new master is ready to manage membership changes, and new sites can be added as usual. But the application must not try to add new sites, or remove existing sites, during the mixed-version transitional phase.

To do a non-live upgrade shutdown the entire replication group. Then restart the group with each site configured with the `DB_LEGACY` flag, and in `DB_REP_ELECTION` mode.

### New Functions

- DB_ENV->repmgr_site()
- DB_ENV->repmgr_site_by_eid()
- DB_SITE->set_config()
- DB_SITE->get_config()
- DB_SITE->remove()
- DB_SITE->get_eid()
- DB_SITE->get_address()
- DB_SITE->close()

### Modified Functions

- DB_ENV->rep_set_nsites() is no longer used by the Replication Manager, but is still used by the Base API. It can now be used to change the number of sites dynamically, even when master leases are in use.

### New Events

- `DB_EVENT_REP_SITE_ADDED`
- `DB_EVENT_REP_SITE_REMOVED`
- `DB_EVENT_REP_LOCAL_SITE_REMOVED`
- `DB_EVENT_REP_CONNECT_BROKEN`
- `DB_EVENT_REP_CONNECT_ESTD`
- `DB_EVENT_REP_CONNECT_TRY_FAILED`
- `DB_EVENT_REP_INIT_DONE`

### Removed Functions

- `DB_ENV->repmgr_set_local_site()`
- `DB_ENV->repmgr_add_local_site()`
- `DB_ENV->repmgr_add_remote_site()`
- `DB_ENV->repmgr_get_local_site()`

### New Parameters

The following new parameters are passed to DB_SITE->set_config().

- `DB_BOOTSTRAP_HELPER`
- `DB_GROUP_CREATOR`
- `DB_LEGACY`
- `DB_LOCAL_SITE`
- `DB_REPMGR_PEER`

### New Structure

- `DB_REPMGR_CONN_ERR` encapsulates an EID and an integer system error code.

Prev | Up | Next
Exclusive Transactions in the SQL Layer | Home | Heap Access Method