Those warnings always give me pause, too - but I used mysqlhotcopy in production for about 5 years at my previous place of employment. Probably like the warnings about threading in perl 5.8 - been using threads in production for nearly 2 years without a problem.
Only 2 problems with mysqlhotcopy that I recall, both related to the same poor decision on my part: I hard-coded the list of databases to be backed up in a shell script run by a cron job. Problem #1: when people created new databases, they wouldn't be backed up until we remembered to add them to that shell script. Problem #2: when someone dropped a database, the nightly snapshot started failing until we removed that database name from the shell script. Would've been a lot better if I'd started off using a regex to specify all databases instead (something like --regexp=/./ ). Come to think of it, I don't know if using a regex was an option in 2001 ... I see it in the man page now. Neat-o. I only once had to restore a table "in anger", after one of my staff made use of a poorly qualified delete statment. Worked fine. I did use the hot-copied files several times to set up test databases and later a replication server. Note: using hot-copied files to set up test databases will break replication. Bummer, but quite logical. Dan On 6/29/06, Tim Lucia <[EMAIL PROTECTED]> wrote:
If it were so cut-and-dry, I would know which one to choose ;-) Obviously it's not. I'm leaning towards the mysqlhotcopy because it is way faster, and now I know how to selectively restore. I have a slight concern with the self-professed beta nature of it -- is that unfounded? Tim
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
