MySQL Forge

Resources for the MySQL Community

ServerInterface

TODO: Introduce the subject.

[edit] List of services that backup kernel needs from server to implement its functionality

[edit] Services we agree upon with runtime team

1. List all databases present in the server - needed when user says "BACKUP DATABASE *". There is a debate whether that list should include server's internal databases.
2. List objects belonging to a given database, for each object we need to know its name and type - to create backup catalogue.
3. Get storage engine of a table - to see if a native backup engine can be used for storing table data.
4. Get metadata of a given object (serialization string) - to store it in the metadata section of the backup image.
5. Create an object from a given serialization string (also destructively, if requested) - to re-create objects upon restore.
6. Get version numbers and string for a server - to store it in image's header.
7. Lock/unlock given object(s) - to prevent access to objects which are being restored.
8. Block/unblock commits of active transactions - needed for validity point synchronization.
9. Create and write a separate backup/restore log - to provide more detailed info about these operations.
10. Report errors and warnings to the server - to give feedback about ongoing operation.

[edit] Services we still are discussing about

1. Check if a given object (database) exists - to verify list of databases given by user, to warn user if an object which exists is about to be overwritten. Alternative: report that object doesn't exist when asking for its metadata.
2. Check if given database is an internal server database - to verify list of databases given by user (we don't backup internal databases such as INFORMATION_SCHEMA or MYSQL). Alternative: don't list internal databases.
3. Get name and version of a storage engine - to store it in the header. Alternative: bakup kernel directly asks storage engine.
4. Get native backup engine for a given storage engine if any. Alternative: directly ask storage engine.
5. Get tablespace used by a given table if any - to add it to the catalogue. Alternative: directly ask table's storage engine.
6. Get base views of a given view - to correctly sort view definitions in the metadata section. Shall we also return base tables? What about base objects which do not exist?
7. Check that object in the server is identical to the one saved in the backup image (the same metadata) - to be able to skip creation of an object which already exists (we use this only for handling tablespaces). Shall this service be defined only for tablespaces?
8. Get user privileges - to check if user can perform BACKUP/RESTORE operation. Alternative: all other services check user privileges themselves.
9. Get server's default character set - to store it in the catalogue. Objection: is it really needed?
10. Freeze/unfreeze server's metadata - to prevent metadata changes during backup. Objection: ?
11. Get current server's binlog position - to store the binlog postion of validity point. Alternative: directly ask the binlogging module.
12. Disable/enable foreign key constraint checking - needed for restoring tables. Objection: not needed because restore drivers should be able to restore data without triggering constraint checks.
13. Write entries to server log - to leave trace of performed BACKUP/RESTORE operations in the server log. Alternative: use the exising logging support of the server (i.e. BACKUP and RESTORE commands are logged as any other SQL statement).