15

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.

shgnInc
  • 1,634
  • 3
  • 21
  • 29
bryan kennedy
  • 1,641
  • 3
  • 16
  • 31
  • 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](http://sourceforge.net/projects/automysqlbackup/) I just added the parameter `--single-transaction` and everythings work correctly. – isccarrasco Feb 03 '15 at 19:21
  • Maybe the problem could be a typo? "LOCK TABL" could be "LOCK TABLE" – rubo77 Feb 04 '15 at 09:38

4 Answers4

20

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

sabujp
  • 329
  • 2
  • 4
  • 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 04 '12 at 16:13
12

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

Shlomi Noach
  • 221
  • 2
  • 5
  • 2
    Using 5.5 version and problem persists – artfulrobot Jun 09 '13 at 08: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 03 '14 at 13:01
  • I agree with Shlomi above that skipping the locks only bypasses the real problem. This helped me: http://askubuntu.com/questions/134670/how-do-i-stop-automysqlbackup-throwing-lock-tables-error – workflow Jul 11 '14 at 11:33
3

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

Martin
  • 481
  • 2
  • 5
0

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' )
sebix
  • 4,175
  • 2
  • 25
  • 45
dumolibr
  • 1