|
The dbrecover utility may be used to apply stored transactions from a set
of forward-log files to the database environment. This is typically used as
part of a disaster recovery after restoring the volume files from a recent
backup.
For using dbrecover, the database server must have been running with
FwLog=... configuration option in eloqdb.cfg enabled
(and active). In addition, a recent backup of the database volume files
as well as a complete set of forward log files since this backup must
be available.
usage: dbrecover [options]
options:
-t tmpdir - directory to be used for temporary files
-v - verbose
-d flags - debug flags
-c cfg - configuration file name
-b size - Buffer cache size (MB)
-T timestamp - recover until point in time (incl.)
timestamp formats:
YYYY-MM-DD HH:MM:SS
MM/DD/YYYY HH:MM:SS
DD.MM.YYYY HH:MM:SS
note: any character may be used to separate date and time
time part is optional (defaults to 00:00:00)
The -c command line option is necessary if a database server
configuration file is used which is different from eloqdb.cfg in
its default location.
The -b command line option may be used to specify the
buffer cache size (in MB). If not set, it defaults to 5 MB. Older
Eloquence versions used the BufferCache setting from the database
server configuration file.
The -T option may be used to specify a point-in-time beyond dbrecover stops
applying changes. Once this point is passed, dbrecover will exit. Specifying
the time is optional (defaults to 00:00:00). Date and time may be separated
with space or other characters (shell quoting might be required).
During recovery, incomplete user transactions are stored in temporary
files until they have been completed. Because of this, an appropriate
amount of temporary disk space is needed. By default, these temporary
files are created in the current directory from where the dbrecover
utility has been invoked. This can be overridden with the
-t command line option.
With Eloquence B.08.00 (and B.07.10 patches)
the dbrecover utility was enhanced to support incremental
recovery. Whenever the recovery process fails (e.g. due to
insufficient temporary disk space), the dbrecover utility
may be restarted and should be able to continue from the
previous point.
The original dbrecover utility required starting from the
beginning, i.e. by restoring previous backup first.
When using incremental recovery the server process
MUST NOT be started between dbrecover runs as this would change
the volume files and/or generation count and make subsequent
runs of dbrecover impossible or inconsistent (data corruption).
Also note that any volume file operations outside a transaction context,
like dbvolextend or write mode of dbrepack, dbfsck or dbcfix make
subsequent use of dbrecover impossible until a new baseline backup
of the volume files is created.
After using dbrecover -T for performing a point-in-time recovery,
you should move any unprocessed forward log files "out of the way"
before starting the eloqdb server again. Otherwise the new server
instance might fail to create new forward logs with conflicting
generation numbers and either disable forward logging or panic
(depending on the FwOnFailure setting in eloqdb.cfg).
Please note that it is not supported to use the dbrecover utility on
a SECONDARY server to perform a point-in-time recovery, then later resume
replication. Doing so would very likely result in secondary server data
corruption and/or would cause the secondary server to crash.
For recovering a secondary server to a specified point in time, you may
restore a backup, start the eloqdb in secondary role and then use dbrepl
utility with option -T to apply transactions up to a given point in
time. (these dbrepl -T runs may be done on the primary or secondary system,
depending on where the relevant forward log files are available).
As of B.08.40 the designation of replicated servers and roles was
updated. A master server is now described as primary server and a
former slave server is now described as a secondary server or a
replicated server.
This affects any messages and configuration options. Any previous
config files are fully compatible.
The following example uses dbrecover with option -T to apply transactions
up to a specified point in time. This may be useful to populate a test system
with a desired database state (for example, to re-run failed processing for
error analysis). Another potential use case is recovery from catastrophic user
or software errors that have occurred on a known point in time.
... (volume files were restored from previous backup)
$ dbrecover -c eloqdb.cfg -T '2005-11-27 17:54' -v
Opening root volume
Recovering from forward-log ...
R1: processing forward-log file: '/data/log/fw-4711-1.log'
R1: processing forward-log file: '/data/log/fw-4712-1.log'
14386 actions have been successfully recovered.
Database environment is now up-to-date until Sun Nov 27 17:53:46 2005.
done.
... (move any unprocessed /data/log/fw-*.log "out of the way")
... (eloqdb server may now be started again)
Article on
Database Forward-Logging
and recovery in B.08.10 documentation.
Lab 2.3
on "forward logging and recovery" in Eloquence Workshop
student guide.
|
