From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Description of problem: mysqlhotcopy --allowold -u dbuser -p dbpass dbname /var/lib/mysql/.dbbackup gives me Deleting previous 'old' hotcopy directory ('/var/lib/mysql/.dbbackup/dbname_old') Existing hotcopy directory renamed to '/var/lib/mysql/.dbbackup/dbname_old' DBD::mysql::db do failed: You have an error in your SQL syntax near '` READ' at line 1 at /usr/bin/mysqlhotcopy line 438. This worked without fail on Redhat 9. Perhaps the problem is in perl-DBD-MySQL-2.9002-1 I'll leave it to the experts to determine that. Version-Release number of selected component (if applicable): mysql-3.23.58-4 How reproducible: Always Steps to Reproduce: 1. Create a mysql database with at least one table 2. Try to back the db up with the mysqlhotcopy command mysqlhotcopy --allowold -u dbuser -p dbpass dbname /path/dbbackuparea 3. Note SQL syntax error, and no backup of the db Actual Results: Deleting previous 'old' hotcopy directory ('/var/lib/mysql/.dbbackup/dbname_old') Existing hotcopy directory renamed to '/var/lib/mysql/.dbbackup/dbname_old' DBD::mysql::db do failed: You have an error in your SQL syntax near '` READ' at line 1 at /usr/bin/mysqlhotcopy line 438. Expected Results: No errors, and a complete backup of the db in question. Additional info:
I tried to reproduce this without success on a current RHEL3 install, which has mysql-3.23.58-1. The mysqlhotcopy script is not different (except in some documentation lines) from that present in RHL 8.0 (mysql-3.23.54a-4), so it's hard to believe that it broke since RHL 9. Perhaps the error is in some underlying Perl component as the complainant suggests? Also: just looking at the script, it seems possible that it could get confused if the database contains odd table names (zero-length strings, names with embedded spaces, or suchlike) but AFAIK MySQL doesn't accept those anyway. Barring a more specific test case, I'll have to mark this WORKSFORME.
Try running Fedora, installing mysql-server, starting the daemon and simply running "mysqlhotcopy mysql /tmp" as root. My one install of RHEL ES doesn't even have mysql-server (postgres only?) as an installation option. I will change the component to perl-DBD-MySQL for this bug, since as you say, the script hasn't changed.
Created attachment 97635 [details] Patch that fixes things on my Fedora box backing up local DB Here's a patch I made for mysqlhotcopy that fixes things if I'm attempting to back up the local databases on a Fedora host. It just takes some erroneous, extra single-ticks ('') out of one line. I don't submit this as a fix because I haven't tested it for backing up remote DBs. Warning, this patches /usr/bin/mysqlhotcopy directly if run with patch -p0 < patchfile, so back up your /usr/bin/mysqlhotcopy if you think it may break something.
Setting priority low since I have a workaround. Also clarified bug Summary.
Verified patch works on Fedora Core 1 w/mysql-3.23.58-4. Is the '' bug sourced from RH or from mysql? Tweeks Rackspace Managed Hosting
This script is straight from the upstream, so it's mysql's issue. I looked at mysql 4.0.17 and found that they've patched the code to add backticks only if not already present in the table name, with the notation # Earlier versions of DBD return table name non-quoted, # such as DBD-2.1012 and the newer ones, such as DBD-2.9002 # returns it quoted. Let's have a support for both. So evidently the critical issue is which version of DBD you have. That's probably why I failed to reproduce it here. Since it looks like we're still not gonna be able to ship mysql 4.* anytime soon :-(, I'll see about backporting this patch.
Thanks Tom, good to hear a fix is in the works. Practically the minute after I posted that patch, I figured it should test to see if the string is already quote-wrapped. I will generate something a little more elegant if you want to save your cycles. Let me know.
I plan to just copy what's in the 4.0.17 script ... not many cycles required ;-)
I have patched this in 3.23.58-8 which will be in Fedora Core 2.
Why not just fix your 32/64bit library issues with MySQL 4 and roll THAT out... no one's using MySQL 3x any more.. nudge nudge.. Tweeks
The problem with MySQL 4 is not a library issue, it's a licensing issue. As long as MySQL AB stick with GPL-ing their client-side libraries, we really can't ship 4 in Red Hat distributions, because we have non-GPL applications that need to link to libmysql. (No, their recently announced FOSS exception doesn't do it for us... read the fine print and you'll see why not.) For all I know there may be a 32/64 bit issue too, but we'll never get around to finding out as long as we can't legally ship the code.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-597.html
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-569.html