15
votes

I am having trouble running mysqldump as the mysql root user. When I try to backup the mysql table I get this error:

mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user
'root'@'localhost' for table 'cond_instances' when using LOCK TABLES

Anyone seen that before? I've seen some references to my mysql and my mysqldump being different versions but when I run which they are in the same directory.

I am running MySQL 5.5.8.

4
  • 1
    Do you still get the error if you run mysqldump with --skip-add-locks ?
    – Martin
    May 11, 2011 at 14:31
  • 1
    Aha, that fixed it. I realized just now that it wasn't the mysql table, it was the performance_schema table, which I see in some docs requires the --skip-add-locks. May 11, 2011 at 17:00
  • I had the same problem... I'm using automysqlbackup I just added the parameter --single-transaction and everythings work correctly. Feb 3, 2015 at 19:21
  • Maybe the problem could be a typo? "LOCK TABL" could be "LOCK TABLE"
    – rubo77
    Feb 4, 2015 at 9:38

4 Answers 4

3
votes

Add --skip-add-locks to your mysqldump command

20
votes

--skip-add-locks doesn't work :

# mysqldump -u root -p`cat mysqlRoot.txt` --databases performance_schema --routines --quote-names --skip-add-locks > mysql_performance_schema

mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES

you want --skip-lock-tables instead

1
  • 1
    This fixed it for me. I edited the automysqlbackup executable (on my install, in /usr/local/bin) to modify the declaration of opt and opt_fullschema to add in the --skip-lock-tables. The new config was opt=( '--quote-names' '--opt' '--skip-lock-tables' ) and opt_fullschema=( '--all-databases' '--routines' '--no-data' '--skip-lock-tables' ) Aug 4, 2012 at 16:13
12
votes

(I realize this comes 8 months late)

This is not a problem of locks, and the offered solutions merely bypass the real problem:

A 5.5 mysqldump application should not export the performance_schema database in the first place.

Based on my previous experience, I suggest that the mysqldump program you have used is a 5.1 version. How to tell? Issue:

mysqldump --version

A 5.1 client is unaware of the "futuristic" existence of performance_schema and therefore attempts to dump it. It is unaware that it should not.

Try and find the 5.5 version, and use it for dumping, without adding the suggested locks, and this should work well.

4
  • 2
    Using 5.5 version and problem persists Jun 9, 2013 at 8:07
  • 1
    mysqldump Ver 10.13 Distrib 5.5.32, for debian-linux-gnu (x86_64) has the same issue...
    – Piku
    Aug 30, 2013 at 23:20
  • 2
    if you're using automysqlbackup like some of the users above, you need to add 'performance_schema' to CONFIG_db_exclude parameter in your automysqlbackup.conf Jun 3, 2014 at 13:01
  • I agree with Shlomi above that skipping the locks only bypasses the real problem. This helped me: askubuntu.com/questions/134670/…
    – workflow
    Jul 11, 2014 at 11:33
0
votes

As mentioned by Shlomi Noach, performance_schema is not supposed to be backed up.

The easy way to fix this is to set the following in your config file:

CONFIG_db_exclude=( 'performance_schema' 'information_schema' )

Not the answer you're looking for? Browse other questions tagged .