Andreas Almroth, 22.10.2009 21:13:
> Storing metadata about backups in the local info schema database just about as useful
> as expecting air freely available when having a walk on the moon tomorrow (or the next 50+
> years or so). If any meta data is to be stored it should be out-of-band, e.g. a separate
> MySQL server (physical apart). Ok, yes, store info local by all means, but also have a
> copy elsewhere for use as redundant protection and easy access.
Do you refer to my comment about a thinkable
MySQL's INFORMATION_SCHEMA database tables do not store data. They just
provide a SELECTable interface to retrieve information from modules
within the running system. On SELECT, functions are called that request
information from live counters or such. The information is then
presented in form of table rows and columns.
One prominent table is INFORMATION_SCHEMA.PROCESSLIST. It selects
information about currently running threads. For example, which
operation they proceed at the moment. I think it is obvious that this is
not data "stored in a local info schema database".
An INFORMATION_SCHEMA.BACKUP_LOCATIONS table would call a backup storage
module service to retrieve a list of currently available backup
locations from all storage modules that the SELECT's WHERE condition
includes (or from all).
> But having said that, I'm with Rafal here, we need to contain the amount of work for
> now, thus limit the scope for the first initial BSM framework. We could continue for
> months discussing features that may be interesting. My experience tells me, do not
> over-engineer! The product will never be released then.
Ok. I'll no longer ask for it then. My main intention was to point out
that management functions do not necessarily break SQL standards.
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028