Chapter 12.  Berkeley DB Replication

Table of Contents

Replication introduction
Replication environment IDs
Replication environment priorities
Building replicated applications
Replication Manager methods
Base API Methods
Building the communications infrastructure
Connecting to a new site
Managing Replication Manager Group Membership
Adding Sites to a Replication Group
Removing Sites from a Replication Group
Primordial Startups
Upgrading Groups
Managing Replication Files
Running Replication Manager in multiple processes
One replication process and multiple subordinate processes
Persistence of local site network address configuration
Programming considerations
Handling failure
Other miscellaneous rules
Running Replication using the db_replicate Utility
One Replication Process and Multiple Subordinate Processes
Common Use Case
Avoiding Rollback
When to Consider an Integrated HA Application
Choosing a Replication Manager Ack Policy
Elections
Synchronizing with a master
Delaying client synchronization
Client-to-client synchronization
Blocked client operations
Clients too far out-of-date to synchronize
Initializing a new site
Bulk transfer
Transactional guarantees
Master Leases
Changing Group Size
Read your writes consistency
Getting a token
Token handling
Using a token to check or wait for a transaction
Clock Skew
Using Replication Manager message channels
DB_CHANNEL
Sending messages over a message channel
Receiving messages
Special considerations for two-site replication groups
Network partitions
Replication FAQ
Ex_rep: a replication example
Ex_rep_base: a TCP/IP based communication infrastructure
Ex_rep_base: putting it all together
Ex_rep_chan: a Replication Manager channel example

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.

There are two ways to build replicated applications. The simpler way is to use the Berkeley DB Replication Manager. The Replication Manager provides a standard communications infrastructure, and it creates and manages the background threads needed for processing replication messages.

The Replication Manager implementation is based on TCP/IP sockets, and uses POSIX 1003.1 style networking and thread support. (On Windows systems, it uses standard Windows thread support.) As a result, it is not as portable as the rest of the Berkeley DB library itself.

The alternative is to use the lower-level replication "Base APIs". This approach affords more flexibility, but requires the application to provide some critical components:

  1. A 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.

(Note that Replication Manager does not provide wire security for replication messages.)

The following pages present various programming considerations, many of which are directly relevant only for Base API applications. However, even when using Replication Manager it is important to understand the concepts.

Finally, the Berkeley DB replication implementation has one other additional feature to increase application reliability. Replication in Berkeley DB is implemented to perform database updates using a different code path than the standard ones. This means operations that manage to crash the replication master due to a software bug will not necessarily also crash replication clients.

For more information on the replication manager operations, see the Replication and Related Methods section in the Berkeley DB C API Reference Guide.