Die mysql-Tabelle kann nicht mit mysqldump gesichert werden. SELECT, LOCK TABL-Befehl für 'cond

15

Ich habe Probleme beim Ausführen mysqldumpals MySQL-Root. Wenn ich versuche, die mysqlTabelle zu sichern, erhalte ich folgende Fehlermeldung:

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

Hat das schon mal jemand gesehen? Ich habe gesehen, dass einige Verweise auf mein mysql und mein mysqldump unterschiedliche Versionen sind, aber wenn ich sie ausführe, befinden sie sich im selben Verzeichnis.

Ich führe MySQL 5.5.8 aus.

mysql database-backup

— Bryan Kennedy
quelle

1

Bekommen Sie immer noch den Fehler , wenn Sie laufen mysqldumpmit --skip-add-locks?

— Martin

1

Aha, das hat es behoben. Mir ist gerade klar geworden, dass es nicht die mysql-Tabelle ist, sondern die performance_schema-Tabelle, für die in einigen Dokumenten die --skip-add-locks erforderlich sind.

— Bryan Kennedy

Ich hatte das gleiche Problem ... Ich verwende automysqlbackup. Ich habe gerade den Parameter hinzugefügt --single-transactionund alles funktioniert korrekt.

— isccarrasco

Vielleicht könnte das Problem ein Tippfehler sein? "LOCK TABL" könnte "LOCK TABLE" sein

— rubo77

3

Fügen Sie Ihrem mysqldump-Befehl --skip-add-locks hinzu

— Martin
quelle

20

--skip-add-locks funktioniert nicht:

# 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

Sie möchten stattdessen --skip-lock-tables

— Sabujp
quelle

1

Das hat es für mich behoben. Ich habe die ausführbare Datei automysqlbackup (bei meiner Installation in / usr / local / bin) bearbeitet, um die Deklaration von opt und opt_fullschema zu ändern und in die --skip-lock-tables einzufügen. Die neue Konfiguration war opt = ('--quote-names' '--opt' '--skip-lock-tables') und opt_fullschema = ('--all-databases' '--routines' '--no- data '' --skip-lock-tables ')

— Ted Pennings

12

(Mir ist klar, dass dies 8 Monate zu spät kommt)

Dies ist kein Problem von Sperren, und die angebotenen Lösungen umgehen lediglich das eigentliche Problem:

Eine 5.5 mysqldump- Anwendung sollte die performance_schemaDatenbank nicht in erster Linie exportieren .

Aufgrund meiner bisherigen Erfahrungen schlage ich vor, dass es sich bei dem von mysqldumpIhnen verwendeten Programm um eine 5.1- Version handelt. Wie zu sagen Problem:

mysqldump --version

Ein 5.1- Client ist sich der "futuristischen" Existenz nicht bewusst performance_schemaund versucht daher, sie zu löschen. Es ist nicht bewusst, dass es nicht sollte.

Versuchen Sie, die 5.5- Version zu finden und zum Speichern zu verwenden, ohne die vorgeschlagenen Sperren hinzuzufügen. Dies sollte gut funktionieren.

— Shlomi Noach
quelle

2

Mit 5.5-Version und Problem bleibt

— Artfulrobot

1

mysqldump Ver 10.13 Distrib 5.5.32 für debian-linux-gnu (x86_64) hat das gleiche Problem ...

— Piku

2

Wenn Sie automysqlbackup wie einige der oben genannten Benutzer verwenden, müssen Sie den Parameter CONFIG_db_exclude in Ihrer automysqlbackup.conf

— Matija Nalis

Ich stimme Shlomi zu, dass das Überspringen der Schlösser nur das eigentliche Problem umgeht. Dies hat mir geholfen: askubuntu.com/questions/134670/…

— Workflow

0

Wie von Shlomi Noach erwähnt, soll performance_schema nicht gesichert werden.

Die einfache Möglichkeit, dies zu beheben, besteht darin, in Ihrer Konfigurationsdatei Folgendes festzulegen:

CONFIG_db_exclude=( 'performance_schema' 'information_schema' )

— dumolibr
quelle

Die mysql-Tabelle kann nicht mit mysqldump gesichert werden. SELECT, LOCK TABL-Befehl für 'cond_instances' verweigert [closed]