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).
            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.
        
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
            DB_ENV->repmgr_set_local_site()
            DB_ENV->repmgr_add_local_site()
            DB_ENV->repmgr_add_remote_site()
            DB_ENV->repmgr_get_local_site()
            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