SUMMARY
-------
Make Archive engine support the backup handler API so that we have
a prototype engine and can use this to experiment with the server
backup algorithm.
DEPENDENCIES
------------
This task is waiting for BUG#33023.
DESCRIPTION
-----------
Make the Archive engine support the backup API.
NOTES
-----
Brian says that Archive is probably esieast engine to add backup support to.
The ARCHIVE backup engine will be of "at begin" type. It sends all the backup data
*after* creating a validity point.
In ARCHIVE engine each table is stored using two files: meta file (.ARM
extension) and data file (.ARZ extension). The latter is compressed using zlib
library.
Backup driver functionality
---------------------------
When creation of a validity point is requested, current meta file and the
current position in the data file are saved for each table. Then, in the final
phase of backup, first the (saved) contents of the meta file is sent and then
the data file is dumped up to the saved position. This is done for each table in
the backup image, using the stream corresponding to that table. The first block of
the stream contains contents of the meta file, the following blocks contents of
the data file. The common stream is not used (empty).
Note that no special preparations are needed for creation of validity point. The
driver is ready for it immediately after the first call to get_data().
Restore driver functionaliy
---------------------------
Driver collects metadata and table data from the backup stream sent by the
kernel and saves them in the files appropriate for each table.
The backup engine functionality is implemented using the following classes (all
defined inside archive_backup namespace):
Engine - implements the backup engine interface,
Backup - backup driver implementation,
Restore - restore driver implementation,
Table_backup - class providing methods for, and encapsulationg state of the
backup process of a single table,
Table_restore - ditto for restoring a table,
Tabel - represents a single table stored in ARCHIVE engine, it knows about
meta and data files of that table.
Backup driver
=============
A driver can be in one of the following states:
START : after creation, before backup process was initialized with begin()
WAITING : after begin(), waiting for validity point creation
(lock()/unlock()). No data is being transferred.
DUMPING : After creation of validity point. Tables' backup data is being sent
via get_data() method.
DONE : When backup data of all tables has been sent.
ERROR : When error was detected.
The current state is kept in state member.
The data for each table is collected using an instance of Table_backup class.
When begin() method of the driver is executed, a list of Table_backup objects,
one per each table in the image, is created.
Validity point is created by calling save_current_state() method for each
Table_backup object. After that, when driver enters DUMPING state, get_data()
calls are forwarded to the Table_backup objects which send backup data of the
corresponding table. Backup data is dumped one table at a time. The stream
member keeps the number of the table being currently dumped. When all data of
that table is written, the driver proceeds to the next table.
The save_current_state() method of Table_backup class works as follows. First it
calls flush() method of table's handler so that all pending data is written to
disk. Then it creates copy of the meta file and then reads and saves the end
position of the data file. In the future, new data might be appended to the data
file, but the backup image will contain only data up to the saved position.
Note: current implementation performs disk operations while saving current data
state (inside the lock() method). This is unacceptable as lock() should return
immediately. This should be fixed in a final implementation.
A possible solution (suggested by Brian) is that during lock() call only a flag
is set. The save_current_state() method will be called before first get_data()
call or first change of table data, whichever comes first.
Restore driver
==============
It has a list of Table_restore instances, one per each table in the backup
image. When next block of backup data arrives from the backup kernel, it is
forwarded to the Table_restore object determined by the number of stream from
which the block comes. A Table_restore instance saves first received block of
data in a metafile and all the following blocks in a data file.
Limitations
===========
- Freezing table data after lock() call, as required by backup protocol, is
not implemented.
- The lock() method of backup driver performs disk operations.
- Backup/restore canceling is not implemented.
- It is assumed that whole contents of a metafile (around 400 bytes) will fit
into a single buffer provided by kerenel.
.
You must be logged in to tag this worklog