Impossible de sauvegarder la table mysql avec mysqldump. SELECT, commande LOCK TABL refusée pour «cond

15

J'ai du mal à courir en mysqldumptant qu'utilisateur root mysql. Lorsque j'essaie de sauvegarder la mysqltable, j'obtiens cette erreur:

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

Quelqu'un a vu ça avant? J'ai vu quelques références à mon mysql et à mon mysqldump étant des versions différentes mais quand je les lance, elles se trouvent dans le même répertoire.

J'utilise MySQL 5.5.8.

mysql database-backup

— Bryan Kennedy
source

1

Recevez-vous toujours l'erreur si vous exécutez mysqldumpavec --skip-add-locks?

— Martin

1

Aha, ça l'a réparé. Je viens de réaliser que ce n'était pas la table mysql, c'était la table performance_schema, que je vois dans certains documents nécessite les --skip-add-locks.

— Bryan Kennedy

J'ai eu le même problème ... J'utilise automysqlbackup Je viens d'ajouter le paramètre --single-transactionet tout fonctionne correctement.

— isccarrasco

Peut-être que le problème pourrait être une faute de frappe? "LOCK TABL" pourrait être "LOCK TABLE"

— rubo77

3

Ajoutez --skip-add-locks à votre commande mysqldump

— Martin
source

20

--skip-add-locks ne fonctionne pas:

# 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

vous voulez plutôt --skip-lock-tables

— sabujp
source

1

Cela m'a arrangé. J'ai édité l'exécutable automysqlbackup (sur mon installation, dans / usr / local / bin) pour modifier la déclaration de opt et opt_fullschema à ajouter dans les tables --skip-lock-tables. La nouvelle configuration était opt = ('--quote-names' '--opt' '--skip-lock-tables') et opt_fullschema = ('--all-databases' '--routines' '--no- data '' --skip-lock-tables ')

— Ted Pennings

12

(Je réalise que cela arrive 8 mois en retard)

Ce n'est pas un problème de verrous, et les solutions proposées contournent simplement le vrai problème:

Une application 5.5 mysqldump ne devrait pas exporter la performance_schemabase de données en premier lieu.

Sur la base de mon expérience, je suggère que le mysqldumpprogramme que vous avez utilisé est un 5.1 la version. Comment dire? Problème:

mysqldump --version

Un client 5.1 n'est pas au courant de l'existence "futuriste" performance_schemaet tente donc de le vider. Il ignore qu'il ne devrait pas.

Essayez de trouver la version 5.5 et utilisez-la pour le vidage, sans ajouter les verrous suggérés, et cela devrait bien fonctionner.

— Shlomi Noach
source

2

L'utilisation de la version 5.5 et le problème persiste

— artfulrobot

1

mysqldump Ver 10.13 Distrib 5.5.32, pour debian-linux-gnu (x86_64) a le même problème ...

— Piku

2

si vous utilisez automysqlbackup comme certains des utilisateurs ci-dessus, vous devez ajouter 'performance_schema' au paramètre CONFIG_db_exclude dans votre automysqlbackup.conf

— Matija Nalis

Je suis d'accord avec Shlomi ci-dessus que sauter les verrous ne contourne que le vrai problème. Cela m'a aidé: askubuntu.com/questions/134670/…

— workflow

0

Comme mentionné par Shlomi Noach, performance_schema n'est pas censé être sauvegardé.

La solution la plus simple consiste à définir les éléments suivants dans votre fichier de configuration:

CONFIG_db_exclude=( 'performance_schema' 'information_schema' )

— dumolibr
source

Impossible de sauvegarder la table mysql avec mysqldump. SELECT, commande LOCK TABL refusée pour «cond_instances» [fermé]