An important feature of each database system is the ability to save consistent backups and, for example in case of a system crash enable the database admiistrator to perform a fast and consistent restore of previous saved data.
In terms of archiving, a cego database can run in two modes: disabled or enabled archive log mode.
In disabled mode, completed written redolog files are not copied to the archive location and are overwritten
in a cyclic manner. This enables the database to recover from the last written checkpoint up to the last written log entry. In case of a system crash, this avoids any data loss.
To recover from an earlier database backup, a subsequent sequence of written log files is required.
Enabling the archiv log modes enables the database to write all completed aalogfiles to a dedicated
archive log location.
If a database recovery is required, the last available online or offline backup is restored and all
subsequent archive log files are provided in the archive log location.
Then a recovery of the database is triggered to roll forward to the most current database state.
For more information about setting up the database archiving mode, please see section Archive log mode at the description of teh admin manager cgadm.
The way to to a data restore and recovery is explained in the following chapter.
8.1 Offline backup
The first method to backup a tableset is to create an offline backup. For this, the tableset is offline and all tableset files are in a
clean and consistent state. Then, the backup can be perfomed on filesystem level using standard file archiving utilies ( tar, zp, cpio, ... ).
For a complete backup, the following files should be saved
- XML configuration file
- Tableset system file ( cego_<tableset>.sys )
- Tableset temp file ( cego_<tableset>.temp )
- Tableset data files ( <datafile 1> - <datafile N> )
The names of the database files must correspond with your definitions from the cego XML configuration file (cegodb.xml)
If the backup has been finished, the database can be started again and the operation can be continued.
Normally offline backups are performed, if an appropriate planned downtime is available and a backup
for a fast database restore is required ( e.g. a database copy ).
8.2 Online backup
For high available database systems, it is often difficult to get any downtime to perform an offline backup.
For this reasons, databases also must provide a way to perform backups while running
and allow to restore this data to a consitent and actual database state.
Cego provides two ways of doing an online backup.
8.2.1 External backup
A common way to perform online backups is just to save the current active datafiles and restore all written blocks
to the original state later on by the recovery procedure.
For this, all modified blocks of each datafile must be saved to the database logfiles.
Later on, while the database is recovered from the restored datafiles, the saved blocks must be copied back to the datafiles.
To perform an online backup with Cego, the corresponding tableset must be setup to online backup mode.
This is done with the following command
CGADM > begin backup for TS1;
mediator on geek : Backup mode started
|
Now the datafiles can be saved to an appropriate backup location. You can list up all relevant datafiles
for backup using the following admin command
CGADM > list bufile for TS1;
+---------------------+
| BUILEINFO |
| FILENAME |
+---------------------+
| ./db/tsticket.xml |
| ./db/chkdb_TS1.sys |
| ./db/chkdb_TS1.temp |
| ./db/data01.dbf |
+---------------------+
mediator on dude.local : Tableset information retrieved
ok ( 0.031 s )
|
From shell level, you can create directly a backup tar file using the following command
$ tar -cvf bu.tar `cgadm --server=localhost --port=2200 --user=cgadm/cgadm --raw --cmd="list bufile for TS1"`
|
Don't forget to use the raw mode switch to avoid any formatting characters.
The backup ticket, which must be saved together with the table set datafiles contains important table set information
which is needed, if the backup data is restored.
After all files have been saved, the backup mode can be finished.
CGADM > end backup for TS1;
mediator on geek : Backup mode ended
ok ( 0.006 s )
|
8.2.2 Internal backup
In the first way, a synchronized and consistent copy of the database is performed
using the sync escape command.
This means, after a consistent checkpoint is written and before the buffer pool is released for further transaction
processing, a escape command can be defined to perform a backup of the database.
Since the command is performed using a forked subshell, the escape command contains any shell command which may be useful to perform
the backup. We recommend to call a backup utility script to save all required data.
The escape command is given as a string argument to the cgadm sync command
CGADM > sync TS1 with './save_TS1' timeout 10;
Tableset in sync with escape command
ok ( 0.006 s )
|
In a very simple case, the backup script might look like the following
#!/bin/bash
tar -cvf TS1.tar cegodb.xml cegodb_TS1.sys cegodb_TS1.temp data*.dbf redolog*.log
gzip -f TS1.tar
|
Make a snapshot with ZFS :
#!/bin/sh
tstamp=`date '+%d.%m.%Y-%H.%M.%S'`
snapname=snap-$tstamp
ssh s96sapts zfs snapshot sapts_pool/saptv06@$snapname
|
8.3 Tableset recovery
To recover a tableset from an online or offline backup, several steps have been performed.
First make sure the corresponding tableset is in offline state. This is done using the cgadm
admin client. For the sample tableset TS1, you make
CGADM > stop tableset TS1;
mediator on dude.local : Tableset stopped
ok ( 0.050 s )
|
Now the saved datafiles and the backup ticket can be restored to the appropriate location.
( To list all relevant files, you can use the "list bufile" admin command )
If required, you can set up an external log manager, which provides the requested archive log files in a
defined archive destination.
To set up the external logmanager /usr/local/bin/cglogmng, you have to add the corresponding entry as shown below
CGADM > set logmng '/usr/local/bin/cglogmng';
mediator on dude.local : Log Manager set up
ok ( 0.031 s )
|
CGADM > set logmng 'NONE';
mediator on dude.local : Log Manager set up
ok ( 0.031 s )
|
The logmanager is called with the following synopsis
cglogmng <archfile> <archpath1:archpath2:....>
|
If the return code is 0, the given archived logfile is available and was restored succesful
to one of the defined archive path ( colon separated list ).
The return code is 1, if the logfile does not exists in the log archive.
In case of any exception, a value of 2 is returned.
A simple external log manager program might look like
#!/bin/bash
ARCHFILE=$1
ARCHPATH=$2
TAPEPATH=./tape
if [ -e "$TAPEPATH/$ARCHFILE" ]
then
TARGETPATH=`echo $ARCHPATH | awk -F: '{ print $1 }'`
cp $TAPEPATH/$ARCHFILE $TARGETPATH
if [ $? -eq 0 ]
then
exit 0
else
# a problem occured while providing the file
exit 2
fi
else
# requested logfile is not available
exit 1
fi
|
Now the recovery of the tableset can be started with the following command
CGADM > recover tableset TS1;
mediator on dude.local : Tableset recovered to lsn 24506
ok ( 2.089 s )
|
After the tableset has been recovered completely, the tableset is in online state and can be
used.
8.4 Log tracing with cglog
With the utility cglog that comes with the cego package, you are table to print the content of a cego logfile
in a readable form. Since the output is well formed, it is also useful for further processing.
This might be useful, to check the consistency of the logfile.
The program is called with the required logfile as an command line argument
This prints out the contents of the log in the following form.
LSN=72:LogAction=SYNC:
--- No log data ---
LSN=73:LogAction=ObjName=t1:ObjType=1:CREATE:
--- Log Data Start ---
ObjectName: t1
ObjectType: table
TableSetId: 1
Table: t1
Schema:
TableName:
TableAlias:
AttrName: a
Type: int
Len: 4
TableName:
TableAlias:
AttrName: b
Type: int
Len: 4
EntrySize = 55
FileId: 0
PageId: 0
LastFileId: 0
LastPageId: 0
EntrySize = 75
--- Log Data End ---
LSN=74:LogAction=ObjName=t1:ObjType=0:INSERT:
--- Log Data Start ---
1|2|
--- Log Data End ---
LSN=75:LogAction=ObjName=t1:ObjType=0:INSERT:
--- Log Data Start ---
2|3|
--- Log Data End ---
|
In the first line of each log entry the main log information is indicated. This is the log sequencenumber, the kind of log entry and optionally object context information regarding the corresponding object the log entry refers to.
For log entries, which contain additional information, this information is encapsulated in beginning and end control lines.
