No se puede hacer una copia de seguridad de la tabla mysql con mysqldump. SELECCIONE, comando LOCK TABL denegado para 'cond_instances' [cerrado]

15

Tengo problemas para ejecutar mysqldumpcomo usuario root de mysql. Cuando intento hacer una copia de seguridad de la mysqltabla, aparece este error:

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

¿Alguien ha visto eso antes? He visto algunas referencias a mi mysql y mi mysqldump que son versiones diferentes pero cuando ejecuto que están en el mismo directorio.

Estoy ejecutando MySQL 5.5.8.

Bryan Kennedy
fuente
1
¿Aún recibe el error si corre mysqldumpcon --skip-add-locks?
Martin
1
Ajá, eso lo arregló. Me di cuenta justo ahora que no era la tabla mysql, era la tabla performance_schema, que veo en algunos documentos requiere --skip-add-locks.
Bryan Kennedy
Tuve el mismo problema ... Estoy usando automysqlbackup . Acabo de agregar el parámetro --single-transactiony todo funciona correctamente.
isccarrasco
Tal vez el problema podría ser un error tipográfico? "LOCK TABL" podría ser "LOCK TABLE"
rubo77

Respuestas:

3

Agregue --skip-add-locks a su comando mysqldump

Martín
fuente
20

--skip-add-locks no funciona:

# 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

quieres --skip-lock-tables en su lugar

sabujp
fuente
1
Esto me lo arregló. Edité el ejecutable automysqlbackup (en mi instalación, en / usr / local / bin) para modificar la declaración de opt y opt_fullschema para agregar en --skip-lock-tables. La nueva configuración era opt = ('--quote-names' '--opt' '--skip-lock-tables') y opt_fullschema = ('--todas las bases de datos' '--rutinas' '--no- data '' --skip-lock-tables ')
Ted Pennings
12

(Me doy cuenta de que esto llega 8 meses tarde)

Este no es un problema de bloqueos, y las soluciones ofrecidas simplemente pasan por alto el problema real:

Una aplicación 5.5 mysqldump no debería exportar la performance_schemabase de datos en primer lugar.

Basado en mi experiencia previa, sugiero que el mysqldumpprograma que ha utilizado es una versión 5.1 . ¿Como decir? Problema:

mysqldump --version

Un cliente 5.1 desconoce la existencia "futurista" performance_schemay, por lo tanto, intenta deshacerse de él. No es consciente de que no debería.

Intente encontrar la versión 5.5 y úsela para descargar, sin agregar los bloqueos sugeridos, y esto debería funcionar bien.

Shlomi Noach
fuente
2
El uso de la versión 5.5 y el problema persiste
artfulrobot
1
mysqldump Ver 10.13 Distrib 5.5.32, para debian-linux-gnu (x86_64) tiene el mismo problema ...
Piku
2
si está utilizando automysqlbackup como algunos de los usuarios anteriores, debe agregar 'performance_schema' al parámetro CONFIG_db_exclude en su automysqlbackup.conf
Matija Nalis
Estoy de acuerdo con Shlomi arriba en que omitir las cerraduras solo pasa por alto el verdadero problema. Esto me ayudó: askubuntu.com/questions/134670/…
workflow
0

Como mencionó Shlomi Noach, se supone que no se debe hacer una copia de seguridad de performance_schema.

La manera fácil de solucionar esto es establecer lo siguiente en su archivo de configuración:

CONFIG_db_exclude=( 'performance_schema' 'information_schema' )
dumolibr
fuente