On Tue, 2004-10-26 at 19:32, Christopher Hicks wrote: > On Tue, 26 Oct 2004, _brian_d_foy wrote: > > In article <[EMAIL PROTECTED]>, Smylers > > <[EMAIL PROTECTED]> wrote: > >> I think the opposite -- that DBIx:: should be for things that are > >> generally usable with DBI, where the "I" is independent. Things such as > >> backing up tend not to be database-independent. > > > > if we work it right, DBIx::Backup could be independent, while > > DBIx::Backup::MySQL implements the MySQL bits. :) > > Exactly. If DBIx::Backup::MySQL has a clean interface it might even > inspire a generic DBIx::Backup and become the MySQL implementation of > DBIx::Backup and spark a revolution in database administration. :)
It has a really clean interface at the moment. You create a backup
object with the path to the conf file as an argument. There are only
three methods on that object intended for internal use. Run the backups,
write the log file (which will happen automatically later) and send an
email to the admin (if configured for it).
The system does not use DBI, so I'm not sure if DBIx is the right place
for it. However, it wouldn't be too hard to have the core backup
management, such as parsing the conf file, determining schedule and
triggering actions separated out into a core Backup module.
I'm not sure how I'd handle the action dispatch interface. I'd really
welcome any suggestions or pointers to code that I could review that
does something like this well already. My initial idea is to specify the
RDMBS to be backed up, which would instruct the base class to load the
appropriate class for that DB. So specifying mysql would load
DBIx::Backup::mysql. Since the actual mechanisms for managing backups
can vary enormously between specific servers, how would I manage that?
I'm thinking I could maintain a list of possible valid actions, such as
flush logs, rotate logs, backup databases, rotate backups, etc., which
the base module would 'test' to see if available for the specified
server type.
The last question (assuming those ideas are on the right track at least)
would be how that would be specified in the conf file. Currently it's
fairly specific for the language of MySQL. See the conf excerpt below
for an example. I can see how it would be fairly easy to just specify
the databases to be backed up when, etc. But there are many things in
the conf file the system would need specific to the server targeted
(hmmm, I should also provide a way to specify multiple servers - why
not). ... I suppose if each specific backup module provides example or
default conf arguments that would be cut and pasted into conf sections
for that type of server and edited as needed, it would work largely as
it does now, with just a little more work during installation.
OK, I've rambled a bit. Sorry this email is a bit in live mode. Since
there does appear to be some real interest in this project, I've
attached the current version (the first functional port to a module
style) for reference. Thank you all _very_ much for the feedback.
Whether or not this ends up under DBIx:: or somewhere else, I am
definitely interested in reworking it so that it might be a reasonable
starting point for a common backup scheduling mechanism, which will
hopefully be fairly portable. <something::?>Backup::MySQL
## mysqladmin ##
# list of options given directly to mysqladmin
#
# verbose - generate more verbose messages
#
# force - continue even if the is an SQL error
mysqladmin:
options:
- verbose
- force
# - etc
## mysqldump ##
# options to be given to mysqldump
# change this to use opt instead
mysqldump:
options:
- opt
- force
- set-variable=net_buffer_length=1M
## backup-databases ##
#
# Logs will be backed up every time the backup program is run, unless
# that activity is specifically turned off. The logs will always be
# flushed and backed up whenever the databases are backed up. This is
# not considered optional.
# We recommend running it daily.
#
# List all the days you want your databases backed up as well in a coma
# seperated list:
# days: Mon,Wed,Sat
# For most sites, once a week + daily logs is probably sufficient
backup:
databases:
- mysql
days: Sat
--
Sean Quinlan <[EMAIL PROTECTED]>
MySQL-Backup-0.8.tar.gz
Description: application/compressed-tar
signature.asc
Description: This is a digitally signed message part
