Red Hat Bugzilla – Bug 877557
mysqldump from 5.1.66 fails against 5.0 server
Last modified: 2013-11-21 15:40:42 EST
Description of problem: mysqldump from 6.3 can not dump mysql system table from 5.8 Version-Release number of selected component (if applicable): client on 6.3 mysql-5.1.66-1.el6_3 server on 5.8 mysql-server-5.0.95-1.el5_7.1 How reproducible: try a mysqldump after updating client to https://rhn.redhat.com/errata/RHSA-2012-1462.html Steps to Reproduce: # mysqldump --opt --extended-insert --create-options --default-character-set=utf8 --routines --user="backup" -p --host="XXX" --port="3306" --ssl-ca=/etc/pki/tls/certs/xxx.cert --databases mysql Actual results: Error: Couldn't read status information for table general_log () mysqldump: Couldn't execute 'show create table `general_log`': Table 'mysql.general_log' doesn't exist (1146) The dump is not made. Expected results: A dump of the mysql system table without error Additional info: This was working fine before the upgrade. A downgrade to 5.1.61-4.el6 restores the expected behaviour.
This seems to be the same issue previously filed upstream at http://bugs.mysql.com/bug.php?id=65670
(In reply to comment #2) > This seems to be the same issue previously filed upstream at > http://bugs.mysql.com/bug.php?id=65670 I've submitted a patch to the upstream report, that checks if tables `general_log` and `slow_log` exist before reading their structure. We'll see what upstream will say if anything.
This problem occurs to me also (client 5.1.69-1, RHEL 6.4). Any idea about when the patch will be integrated on official package?
Note that http://bugs.mysql.com/bug.php?id=65670 suggests a workaround (creating the missing tables). Is it save, i.e. without side effects?
(In reply to comment #4) > This problem occurs to me also (client 5.1.69-1, RHEL 6.4). > > Any idea about when the patch will be integrated on official package? Upstream indicated desire to include it, but when or if it will happen, that's a question really for upstream. (In reply to comment #5) > Note that http://bugs.mysql.com/bug.php?id=65670 suggests a workaround > (creating the missing tables). Is it save, i.e. without side effects? I believe it shouldn't do any harm, if the tables' structure is correct.
Created attachment 778112 [details] patch proposed to upstream According to upstream bug report [1], this bug is going to be fixed in upcoming 5.5.33. We don't know if they used the proposed patch, but I'm rather attaching it here for the case upstream would make the bug report private. [1] http://bugs.mysql.com/bug.php?id=65670
Created attachment 781529 [details] patch actually used by upstream This is a back-ported patch from 5.5.33.
For reproducing, we need to have mysql-5.1.66 or newer installed and mysql-5.0.x running somewhere else. Steps to reproduce: On the host where mysql-5.0.x is installed (in this example 192.168.122.106) 1) # service mysqld start 2) # mysql -u root mysql 3) mysql> create user 'dumper'@'%' identified by '123456'; 4) mysql> grant all on mysql.* to 'dumper'@'%'; 5) mysql> flush privileges; On the host where mysql-5.1.66 or newer is installed: 1) # mysqldump -h 192.168.122.106 -u dumper -p --databases mysql 2) # echo $? Actual results: mysqldump: Couldn't execute 'show create table `general_log`': Table 'mysql.general_log' doesn't exist (1146) 2 Expected results: -- MySQL dump 10.13 Distrib 5.1.70, for redhat-linux-gnu (x86_64) <snipped> -- Dump completed on 2013-08-09 10:07:52 0
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1647.html