Berkeley DB Reference Guide: Berkeley DB Replication

Introduction

Berkeley DB includes support for building highly available applications based on replication. Berkeley DB replication groups consist of some number of independently configured database environments. There is a single master database environment and one or more client database environments. Master environments support both database reads and writes; client environments support only database reads. If the master environment fails, applications may upgrade a client to be the new master. The database environments might be on separate computers, on separate hardware partitions in a non-uniform memory access (NUMA) system, or on separate disks in a single server. As always with Berkeley DB environments, any number of concurrent processes or threads may access a database environment. In the case of a master environment, any number of threads of control may read and write the environment, and in the case of a client environment, any number of threads of control may read the environment.

Applications may be written to provide various degrees of consistency between the master and clients. The system can be run synchronously such that replicas are guaranteed to be up-to-date with all committed transactions, but doing so may incur a significant performance penalty. Higher performance solutions sacrifice total consistency, allowing the clients to be out of date for an application-controlled amount of time.

While Berkeley DB includes the database infrastructure necessary to construct highly available database environments, applications must still provide some critical components:

1. The application is responsible for providing the communication infrastructure. Applications may use whatever wire protocol is appropriate for their application (for example, RPC, TCP/IP, UDP, VI or message-passing over the backplane).

2. The application is responsible for naming. Berkeley DB refers to the members of a replication group using an application-provided ID, and applications must map that ID to a particular database environment or communication channel.

3. The application is responsible for monitoring the status of the master and clients, and identifying any unavailable database environments.

4. The application must provide whatever security policies are needed. For example, the application may choose to encrypt data, use a secure socket layer, or do nothing at all. The level of security is left to the sole discretion of the application.

Replication and Related Methods	Description
DB_ENV->set_rep_transport	Configure replication transport
DB_ENV->rep_elect	Hold a replication election
DB_ENV->set_rep_limit	Limit data sent in response to a single message
DB_ENV->rep_process_message	Process a replication message
DB_ENV->rep_start	Configure an environment for replication
DB_ENV->rep_stat	Replication statistics

Copyright Sleepycat Software