Library Version 18.1.40

Ex_rep: a replication example
Prev | Chapter 12. Berkeley DB Replication | Next

## Ex_rep: a replication example

Ex_rep, found in the `examples/c/ex_rep` subdirectory of the Berkeley DB distribution, is a simple but complete demonstration of a replicated application. The application is a mock stock ticker. The master accepts a stock symbol and a numerical value as input, and stores this information into a replicated database; either master or clients can display the contents of the database, given an empty input line.

There are two versions of the application: ex_rep_mgr uses Replication Manager, while ex_rep_base uses the replication Base API. This is intended to demonstrate that, while the basic function of the application is the same in either case, the replication support infrastructure differs markedly.

The communication infrastructure demonstrated with ex_rep_base has the same dependencies on system networking and threading support as does the Replication Manager (see the Replication introduction). The Makefile created by the standard UNIX configuration will build the ex_rep examples on most platforms. Enter "make ex_rep_mgr" and/or "make ex_rep_base" to build them.

The synopsis for both programs is as follows:

`ex_rep_xxx -h home -l host:port [-MC] [-r host:port] [-R host:port] [-a all|quorum] [-b] [-n sites] [-p priority] [-v]`

where "ex_rep_xxx" is either "ex_rep_mgr" or "ex_rep_base". The only difference is that:

- specifying -M or -C is optional for ex_rep_mgr, but one of these options must be specified for ex_rep_base.

- The -n option is not supported supported by ex_rep_mgr. That option specifies the number of nodes in the replication group. When you use the Replication Manager, this number is automatically determined for you.

The options apply to either version of the program except where noted. They are as follows:

-h
  Specify a home directory for the database environment.
-l
  Listen on local host "host" at port "port" for incoming connections.
-M
  Configure this process as a master.
-C
  Configure this process as a client.
-r
  Identifies the helper site used for joining the group.
-R
  Identifies a remote peer to be used for joining the group. This peer is used for syncing purposes. See Client-to-client synchronization for more information.
-a
  Specify repmgr acknowledgement policy of all or quorum. See DB_ENV->repmgr_set_ack_policy() for more information (ex_rep_mgr only.)
-b
  Indicates that bulk transfer should be used. See Bulk transfer for more information.
-n
  Specify the total number of sites in the replication group (ex_rep_base only).
-p
  Set the election priority. See Elections for more information.
-v
  Indicates that additional informational and debugging output should be enabled.

A typical ex_rep_mgr session begins with a command such as the following, to start a master:

    ex_rep_mgr -M -p 100 -h DIR1 -l localhost:30100

and several clients:

    ex_rep_mgr -C  -p 50 -h DIR2 -l localhost:30101 -r localhost:30100
    ex_rep_mgr -C -p 10 -h DIR3 -l localhost:30102 -r localhost:30100
    ex_rep_mgr -C -p 0 -h DIR4 -l localhost:30103 -r localhost:30100

In this example, the client with home directory DIR4 can never become a master (its priority is 0). Both of the other clients can become masters, but the one with home directory DIR2 is preferred. Priorities are assigned by the application and should reflect the desirability of having particular clients take over as master in the case that the master fails.

Prev | Up | Next
Replication FAQ | Home | Ex_rep_base: a TCP/IP based communication infrastructure