Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mysql backup quesiton



 Dan Ritter wrote: 
> Stephen Adler wrote: 
>> I need to make sure that on a 24 hr interval, some kind of snap 
>> shot is made of the database... 
> 
> I don't think you'd have any problems...shutting down 
> the database, running mysqldump, gzipping the output and 
> rsyncing it to two or three places. 
> 
> Sometimes the simple solutions are best. 

I agree with Dan that replication is not warranted for this application. 
  mysqldump dump is trivial to set up, and it provides abundant options 
for controlling what gets dumped and whether logs are flushed and tables 
locked before/during the dump. 


Rich Braun wrote: 
> So you could in theory write a program which evaluates the tables ("SHOW TABLE 
> STATUS\G") by Update_time and by Data_length, and backs up just those since 
> the last backup.  Maybe someone has already done that but it'd probably be 
> hard to find, because its usefulness would be limited to particular sites for 
> which an incremental backup is important... 

Yes, such a tool exists. At the November MySQL Meetup on the topic of 
MySQL replication someone mentioned that there is a Perl script for 
doing incremental syncing of two databases. It's used to recover from a 
broken replication. 

http://maatkit.sourceforge.net/


> A note about mysqldump vs. snapshots:  mysqldump is more portable across MySQL 
> versions, so that's the preferred method if you're only using one backup 
> method. 

Right. This of course also applies to the scenario in which you shut 
down the server (or flush the buffers and lock tables) and copy the 
binary database files. 

It's been discussed on this list before. Good for short term backups, 
but not so good for archival storage. 

  -Tom 

-- 
Tom Metro 
Venture Logic, Newton, MA, USA 
"Enterprise solutions through open source." 
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org