From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/rep_ex.html | 238 ++++++++++++++++++---------------- 1 file changed, 126 insertions(+), 112 deletions(-) (limited to 'docs/programmer_reference/rep_ex.html') diff --git a/docs/programmer_reference/rep_ex.html b/docs/programmer_reference/rep_ex.html index 3e5f9e62..f458dbc1 100644 --- a/docs/programmer_reference/rep_ex.html +++ b/docs/programmer_reference/rep_ex.html @@ -14,7 +14,7 @@ -

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: -

+ 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: +

-

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

+

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

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

+

+ 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:

+

+ 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. -

+ 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. +