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.

  • 1
    Do you still get the error if you run mysqldump with --skip-add-locks ? – Martin May 11 '11 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. – bryan kennedy May 11 '11 at 17:00
  • I had the same problem... I'm using automysqlbackup I just added the parameter --single-transaction and everythings work correctly. – isccarrasco Feb 3 '15 at 19:21
  • Maybe the problem could be a typo? "LOCK TABL" could be "LOCK TABLE" – rubo77 Feb 4 '15 at 9:38

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


--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
    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' ) – Ted Pennings Aug 4 '12 at 16:13

(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.

  • 2
    Using 5.5 version and problem persists – artfulrobot Jun 9 '13 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 '13 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 – Matija Nalis Jun 3 '14 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 '14 at 11:33

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 or ask your own question.