|
|
|
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. The only constraint is that all the participants in a replication group all be on machines of the same endianness. (We expect this constraint to be removed in a future release.) 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:
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.
Replication and Related Methods | Description |
---|---|
DB_ENV->rep_elect | Hold a replication election |
DB_ENV->rep_process_message | Process a replication message |
DB_ENV->rep_stat | Replication statistics |
DB_ENV->rep_sync | Replication synchronization |
Replication Configuration | |
DB_ENV->rep_set_config | Configure the replication subsystem |
DB_ENV->rep_start | Configure an environment for replication |
DB_ENV->set_rep_limit | Limit data sent in response to a single message |
DB_ENV->set_rep_transport | Configure replication transport |
Copyright (c) 1996-2005 Sleepycat Software, Inc. - All rights reserved.