- Berkeley DB Reference Guide:
- Berkeley DB Replication
|
|
Applications wanting to use replication to support recovery after catastrophic failure of the master may want to configure a site as a logs-file-only replica. Such clients cannot respond to read (or write) queries but they still receive a complete copy the log files, so that in the event of master failure, a copy of the logs is available.
Log file only clients are configured like other client sites, except they should specify the DB_REP_LOGSONLY flag to the DB_ENV->rep_start method and should specify a priority of 0 to the DB_ENV->rep_elect method.
There are two ways to recover using a log-file-only replica. The simplest way is to copy the log files from the log-file-only replica onto another site (either master or replica) and run catastrophic recovery there. If that is not an option, then recovery must be run on the log-file-only replica, using the log files that have accumulated there. If the log files are entirely self-contained, that is, they start with log file number 1, then a log replica can simply run catastrophic recovery. Obviously, if there are a large number of log files in this case, recovery may take a long time. If the log files are not self-contained, an archival copy of the databases must first be restored onto the replica before running catastrophic recovery. In the latter case (that is, running recovery on the log-file-only replica), once the site returns to being a log-file-only replica, the database files on the log-file-only replica should be removed, and if the log files do not begin with log file number 1, a new set of archival databases should be created from the current master.
More specifically, the log files accumulating on the log-file-only replica can take the place of the log files described in catastrophic recovery section of the Recovery procedures Berkeley DB Reference Guide.
In all other ways, a log-file-only site behaves as other replication clients do. It should have a thread or process receiving messages and passing them to DB_ENV->rep_process_message and must respond to all returns described for that interface.
|
|