Date: Thu, 26 Mar 2009 17:11:08 +0000 From: Pete French <petefrench@ticketswitch.com> To: jake@poptart.org, peter.schuller@infidyne.com Cc: jacks@sage-american.com, freebsd-stable@freebsd.org, fs@freebsd.org Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) Message-ID: <E1Lmt6i-0000PI-T4@dilbert.ticketswitch.com> In-Reply-To: <alpine.BSF.2.00.0903261432350.31074@cyhz.syveoyr.bet>
next in thread | previous in thread | raw e-mail | index | archive | help
> Absolutely. You really must use a tool that interacts with the database
> to perform the backup. Most commercial DBs have hooks that allow the
> backup routines to call out to custom snapshot facilities. One would
> usually request a backup through the database, which would then freeze IO
> to its data files and maybe log files, deal with flushing caches etc and
> then call your snapshot routine. I'm not aware that MySQL and Postgres do
> though so the best you can do is a dump.
mysql can do this - you can flush the tables and acuire a lock
simultaneously so that you can then snapshot the uderlying filesystem
and then release the lock to let everything continue. I use this for taking
database snapshots and it works fine. I stop my slaves before snapshotting
to avoid log files changing underneath me too .... like this...
#!/bin/sh
/usr/local/bin/mysql -usnapuser -psnapuser <<EOF
slave stop;
flush tables with read lock;
system /sbin/zfs snapshot archive/mysql@latest;
unlock tables;
slave start;
EOF
That appears to work fine. I do also do other dumps, but the above
works nicely for a quick and easy snapshot on a slave which can be
rolled back in the case of a crash (and will then update from the master
properly)
-pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Lmt6i-0000PI-T4>