<!--$Id: app.so,v 1.32 2008/04/23 15:49:17 alanb Exp $--> <!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Building replicated applications</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <table width="100%"><tr valign=top> <td><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></b></td> <td align=right><a href="../rep/pri.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/mgr_meth.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p align=center><b>Building replicated applications</b></p> <p>The simplest way to build a replicated Berkeley DB application is to first build (and debug!) the transactional version of the same application. Then, add a thin replication layer: application initialization must be changed and the application's communication infrastructure must be added.</p> <p>The application initialization changes are relatively simple. Replication Manager provides a communication infrastructure, but in order to use the Base replication API you must provide your own.</p> <p>For implementation reasons, all replicated databases must reside in the data directories set from <a href="../../api_c/env_set_data_dir.html">DB_ENV->set_data_dir</a> (or in the default environment home directory, if not using <a href="../../api_c/env_set_data_dir.html">DB_ENV->set_data_dir</a>), rather than in a subdirectory below the specified directory. Care must be taken in applications using relative pathnames and changing working directories after opening the environment. In such applications the replication initialization code may not be able to locate the databases, and applications that change their working directories may need to use absolute pathnames.</p> <p>During application initialization, the application performs three additional tasks: first, it must specify the <a href="../../api_c/env_open.html#DB_INIT_REP">DB_INIT_REP</a> flag when opening its database environment and additionally, a Replication Manager application must also specify the <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag; second, it must provide Berkeley DB information about its communications infrastructure; and third, it must start the Berkeley DB replication system. Generally, a replicated application will do normal Berkeley DB recovery and configuration, exactly like any other transactional application.</p> <p>Replication Manager applications configure the built-in communications infrastructure by calling the <a href="../../api_c/repmgr_local_site.html">DB_ENV->repmgr_set_local_site</a> method once and the <a href="../../api_c/repmgr_remote_site.html">DB_ENV->repmgr_add_remote_site</a> method zero or more times. Once the environment has been opened, the application starts the replication system by calling the <a href="../../api_c/repmgr_start.html">DB_ENV->repmgr_start</a> method.</p> <p>If using the Base replication API, the application calls the <a href="../../api_c/rep_transport.html">DB_ENV->rep_set_transport</a> method to configure the entry point to its own communications infrastructure, and then it calls the <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> method to join or create the replication group.</p> <p>When starting the replication system, an application has two choices: it may choose the group master site explicitly, or alternatively it may configure all group members as clients and then call for an election, letting the clients select the master from among themselves. Either is correct, and the choice is entirely up to the application.</p> <p>For an application that uses the Base replication API, the result of calling <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> is usually the discovery of a master, or the declaration of the local environment as the master. If a master has not been discovered after a reasonable amount of time, the application should call <a href="../../api_c/rep_elect.html">DB_ENV->rep_elect</a> to call for an election.</p> <p>Replication Manager applications have these same two choices. But they configure their start-up behavior simply by setting the flags parameter to the <a href="../../api_c/repmgr_start.html">DB_ENV->repmgr_start</a> method.</p> <p>Consider the case of multiple processes or multiple environment handles that modify databases in the replicated environment. All modifications must be done on the master environment. The first process to join or create the master environment must call both the <a href="../../api_c/rep_transport.html">DB_ENV->rep_set_transport</a> method and the <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> method. Subsequent replication processes must at least call the <a href="../../api_c/rep_transport.html">DB_ENV->rep_set_transport</a> method. Those processes may call the <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> method (as long as they use the same master or client argument). If multiple processes are modifying the master environment there must be a unified communication infrastructure such that messages arriving at clients have a single master ID. Additionally the application must be structured so that all incoming messages are able to be processed by a single <a href="../../api_c/env_class.html">DB_ENV</a> handle.</p> <p>Note that not all processes running in replicated environments need to call <a href="../../api_c/rep_transport.html">DB_ENV->rep_set_transport</a> or <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a>. Read-only processes running in a master environment do not need to be configured for replication in any way. Processes running in a client environment are read-only by definition, and so do not need to be configured for replication either (although, in the case of clients that may become masters, it is usually simplest to configure for replication on process startup rather than trying to reconfigure when the client becomes a master). Obviously, at least one thread of control on each client must be configured for replication as messages must be passed between the master and the client.</p> <p>Any site in a replication group may have its own private transactional databases in the environment as well. A site may create a local database by using the <a href="../../api_c/db_set_flags.html#DB_TXN_NOT_DURABLE">DB_TXN_NOT_DURABLE</a> flag to the <a href="../../api_c/db_set_flags.html">DB->set_flags</a>. The application must never create a private database with the same name as a database replicated across the entire environment as data corruption can result.</p> <p>For implementation reasons, all incoming replication messages must be processed using the same <a href="../../api_c/env_class.html">DB_ENV</a> handle. It is not required that a single thread of control process all messages, only that all threads of control processing messages use the same handle.</p> <p>No additional calls are required to shut down a database environment participating in a replication group. The application should shut down the environment in the usual manner, by calling the <a href="../../api_c/env_close.html">DB_ENV->close</a> method. For Replication Manager applications, this also terminates all network connections and background processing threads.</p> <table width="100%"><tr><td><br></td><td align=right><a href="../rep/pri.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../rep/mgr_meth.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> </body> </html>