3 ms·
I think you could have these solutions when dealing with lots of data, but I'm not an expert in either: MySQL: replicate the database to one or more slaves, an
by JoachimSchipper 16y ago
I think you could have these solutions when dealing with lots of data, but I'm not an expert in either:
MySQL: replicate the database to one or more slaves, and either run mysqldump on a live slave (which should have sufficient capacity, since it's only keeping up with the INSERTs on the master and not handling queries) or take the slave offline, make a backup (EDIT: somehow - I don't really know MySQL all that well) and then make it catch back up (which may not be easy).
rsync: sensible people only create paths of the form f/s/myfile if they are expecting a ton of files. In this case, keeping track of file attributes may be extremely valuable (if UNIX ctime hasn't changed, rsync doesn't need to look at the file at all, which saves a lot of disk I/O.) (EDIT:) I just remembered that rsync tries to preserve hard links, too - and therefore remembers the inode of every file. I'm pretty sure that you can run a machine out of memory with enough small files.