There are two ways that you can choose to implement replication in your transactional application. The first, and preferred, mechanism is to use the pre-packaged replication framework that comes with the DB distribution. This framework should be sufficient for most customers.
If for some reason the Replication Framework does not meet your application's technical requirements, you will have to use the replication APIs available through the Berkeley DB library to write your own custom replication framework.
Both of these approaches are described in slightly greater detail in this section. The bulk of the chapters later in this book are dedicated to these two replication implementation mechanisms.
DB's pre-packaged replication framework exists as a layer on top of the DB library. The replication framework is a multi-threaded implementation that allows you to easily add replication to your existing transactional application. You access and manage the replication framework using special methods and classes designated for its use. Mostly these are centered around the Environment and EnvironmentConfig classes.
The replication framework:
Provides a multi-threaded communications layer using pthreads (on Unix-style systems and similar derivatives such as Mac OS X), or Windows threads on Microsoft Windows systems.
Uses TCP/IP sockets. Network traffic is handled via threads that handle inbound and outbound messages. However, each process uses a single socket that is shared using select().
Note that for this reason, the replication framework is limited to a maximum of 60 replicas (on Windows) and approximately 1000 replicas (on Unix and related systems), depending on how your system is configured.
Requires a single process for the master replica.
Requires that only one instance of the environment handle be used.
Upon application startup, a master can be selected either manually or via elections. After startup time, however, during the course of normal operations it is possible for the replication group to need to locate a new master (due to network or other hardware related problems, for example) and in this scenario elections are always used to select the new master.
If your application has technical requirements that do not conform to the implementation provided by the replication framework, you must write a custom replication framework using the DB replication APIs directly. See the next section for introductory details.
The replication API is a series of Berkeley DB library classes and methods that you can use to build your own replication infrastructure. You should use the replication API only if the replication framework does not meet your application's technical requirements.
To make use of the replication API, you must write your own networking code. This frees you from the technical constraints imposed by the replication framework. For example, by writing your own framework, you can:
Use a threading package other than pthreads (Unix) or Windows threads (Microsoft Windows). This might be interesting to you if you are using a platform whose preferred threading package is something other than (for example) pthreads, such as is the case for Sun Microsystem's Solaris operating systems.
Implement your own sockets. The replication framework uses TCP/IP sockets. While this should be acceptable for the majority of applications, sometimes UDP or even raw sockets might be desired.
Write a multi-process master replica.
For information on writing a replicated application using the Berkeley DB replication APIs, see the Berkeley DB Programmer's Reference Guide.