`mysql_upgrade` está fallando sin ninguna razón real dada

70

Estoy actualizando MySQL 5.1 a 5.5, ejecuto mysql_upgradey obtengo este resultado:

# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

¿Alguna idea sobre dónde buscar lo que está sucediendo (o no está sucediendo?) Para que pueda solucionar lo que está mal y realmente ejecutar mysql_upgrade?

¡Gracias!

Más salida:

# mysql_upgrade --verbose
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-check --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

User time 0.00, System time 0.00
Maximum resident set size 1260, Integral resident set size 0
Non-physical pagefaults 447, Physical pagefaults 0, Swaps 0
Blocks in 0 out 16, Messages in 0 out 0, Signals 0
Voluntary context switches 9, Involuntary context switches 5

# mysql_upgrade --debug-check
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

Tras el cierre de mysqld --skip-grant-tablesvía mysqladmin shutdowny reiniciar MySQL a través de service mysql start, el registro de errores bucles a través de este conjunto de errores una y otra vez:

130730 21:03:27 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
130730 21:03:27 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130730 21:03:27 InnoDB: The InnoDB memory heap is disabled
130730 21:03:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:03:27 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:03:27 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:03:29 InnoDB: Completed initialization of buffer pool
130730 21:03:30 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 588190222435
130730 21:03:30  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 588192055067
130730 21:03:30  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 81298895, file name /var/log/mysql/mysql-bin.006008
130730 21:03:33  InnoDB: Waiting for the background threads to start
130730 21:03:34 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:03:34 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
130730 21:03:34 [Note] Starting crash recovery...
130730 21:03:34 [Note] Crash recovery finished.
130730 21:03:34 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:03:34 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:03:34 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist

Registro de MySQL durante el inicio a través de mysqld_safe --skip-grant-tables

130730 21:19:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130730 21:19:36 [Note] Plugin 'FEDERATED' is disabled.
130730 21:19:36 InnoDB: The InnoDB memory heap is disabled
130730 21:19:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:19:36 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:19:37 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:19:39 InnoDB: Completed initialization of buffer pool
130730 21:19:39 InnoDB: highest supported file format is Barracuda.
130730 21:19:42  InnoDB: Warning: allocated tablespace 566, old maximum was 0
130730 21:19:42  InnoDB: Waiting for the background threads to start
130730 21:19:43 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:19:43 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:19:43 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:19:43 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:19:43 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
130730 21:19:43 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
130730 21:19:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.04.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Según tengo entendido, todos los problemas de estructura / existencia de la tabla (en lo que respecta a las tablas del sistema mysql) deben corregirse ejecutando mysql_upgrade:

mysql  mysql5.5 
— Jim Rubenstein
fuente
También probablemente no valga nada, se mysqldestá ejecutando, con --skip-grant-tablesopción. Me puedo conectar a través mysqlde la terminal sin credenciales, y no obtengo errores a través de syslog o en cualquier otro lugar en el que pueda pensar cuando ejecutomysql_upgrade
— Jim Rubenstein
El Manual de referencia de MySQL cubre la actualización a 5.5 desde 5.1 bastante bien. Si ha seguido todas las instrucciones aquí, vale la pena mencionarlo. Si no lo has hecho, bueno ...
— Aaron Copley
Si su usuario root de mysql no tiene una contraseña, no incluya `-p` en` mysql_upgrade -u root -p`
— Jeferex

Respuestas:

95

Creo que necesita nombre de usuario y contraseña

mysql_upgrade -u root -p

Si no los paso, recibo tu error

Editar : gracias a los comentarios ahora sé que hay otras razones, quizás menos frecuentes, pero es mejor estar al tanto de ellas también

Entonces obtienes ese error cuando

  • no pasaste nombre de usuario y contraseña
  • pasaste tus credenciales, pero estaban equivocadas
  • el servidor MySQL no se está ejecutando
  • las tablas de permisos están arruinadas (entonces debe reiniciar MySQL con mysqld --skip-grant-table)
  • falta la tabla mysql.plugin (verá un error al iniciar MySQL que sugiere ejecutar ... mysql_upgrade, y eso falla. Probablemente tenga alguna configuración obsoleta en my.cnf)
— Riccardo Galli
fuente
23
Este fue exactamente el problema que tuve: ¿por qué demonios no podía simplemente decir "No se pudo autenticar" o "Error de conexión" o algo así? Tan enojado ...
— les2
3
Chicos, ustedes obtienen el mismo error si su contraseña también es incorrecta. así que esté informado
— Yoosaf Abdulla
3
Y obtiene el mismo error si el servidor no se está ejecutando, aunque parece aceptar la contraseña.
— Raman
1
justo cuando la tabla de la base de datos o el formato de la base de datos también están rotos, tampoco funciona, ¡entonces necesitas iniciar el demonio con "mysqld --skip-grant-tables" y ejecutar mysql_upgrade en otro terminal!
— Henning
+1 por esto. Otra razón por la que odio MySQL
— Excalibur,
9

Acabo de encontrar estos síntomas precisos al actualizar de 5.5 a 5.6, y resultó ser un problema de accesibilidad del servicio.

Aunque el cliente cli MySQL podía conectarse a mi instancia de base de datos local con solo un -u y -p proporcionado, también necesitaba especificar -h 127.0.0.1 para mysql_upgrade porque estaba intentando una conexión de archivo de socket y fallaba miserablemente en el intento.

— Halconero Aubrey
fuente
ese fue exactamente mi problema porque ejecuté mysqd así: mysqld --skip-grant-tables --user = mysql
— Rodo
9

Parece un servidor Plesk, cuando se usa Plesk no hay root para Mysql, pero el administrador de Mysql llamó admin, por lo que este comando debería funcionar en Plesk como lo probé antes:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
fuente
Esto funcionó perfectamente para mí
— xarlymg89
5

podría intentar ejecutar estos uno por uno para ver dónde falla:

mysql_upgrade ejecuta los siguientes comandos para verificar y reparar tablas y para actualizar las tablas del sistema: 

mysqlcheck --all-databases --check-upgrade --auto-repair  
mysql < fix_priv_tables  
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

de http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

— user16081-JoeT
fuente
1
Pensé en eso, pero fix_priv_tableses un script generado por mysql_upgradepara arreglar las tablas de privilegio
— Jim Rubenstein
buen punto, tal vez intente solo la primera línea mysqlcheck? E intente ejecutar directamente desde la carpeta bin, fwiw,/usr/bin/mysql_upgrade
— user16081-JoeT
3

Esta pregunta es increíblemente genérica, y me disculpo por eso.

No pude encontrar una causa directa y una solución al problema que tenía, así que recurrí a reinstalar MySQL para ver si eso funcionaba. Resulta que la reinstalación hizo el truco. Esa era una forma lamentable de solucionarlo, pero era la única opción que me quedaba.

Muchas de las otras respuestas a esta pregunta son problemas por los que tuve que trabajar para que mysql_upgrade se ejecute inicialmente, pero por alguna razón, falló porque estaba tratando de ejecutar algunas consultas automáticas y no pude encontrar la documentación sobre la cual consulta que se estaba ejecutando para poder solucionarlos.

— Jim Rubenstein
fuente
Sí, una vez que el directorio de datos de mysql se ha dañado, no hay prácticamente nada que puedas hacer
— Krauser
2

Debe verificar el permiso de todos los archivos en mysql data. Debe ser el mismo propietario de mysql PID (mysql o _mysql). Esto sucede a veces porque restaura los datos del archivo sin el permiso adecuado. Por ejemplo, si sus datos de mysql están bajo / var / lib / mysql

chown -R mysql /var/lib/mysql
— asofyan
fuente
2

Nuestro DBA desinstaló mysql versión 5.0.95 en lugar de simplemente actualizar a 5.5.39. La desinstalación hizo una copia de seguridad del /etc/my.cnfpara /etc/my.cnf.rpmsaveluego eliminarlo, y esto evitó que MySQL se iniciara correctamente:

140902 15:00:57 [ERROR] Plugin 'InnoDB' init function returned error.
140902 15:00:57 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140902 15:00:57 [ERROR] Unknown/unsupported storage engine: InnoDB
140902 15:00:57 [ERROR] Aborting

Puede hacer lo siguiente:

  • Compare los archivos my.cnf manualmente y obtenga la configuración de configuración adecuada para InnoDB

  • Restaure el my.cnf.rpmsavereverso sobre el original (¡compruebe primero si hay alguna nueva configuración predeterminada que deba agregar!

  • Use una herramienta de diferencias como vimdiffpara compararla my.cnf.rpmsavecon la nueva my.cnfy traer de vuelta los ajustes que se hicieron a la configuración de MySQL, incluida la configuración de InnoDB.

    [root]# vimdiff /etc/my.cnf /etc/my.cnf.rpmsave

Hice la última opción, luego pude iniciar MySQL:

root]# service mysqld start
Starting mysqld:                                           [  OK  ]

y ahora mysql_upgradefunciona bien, mysql_upgrade -uroot -pasí que me solicitó la contraseña de root.

[root]# mysql_upgrade -uroot -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
....

¡Espero que esto ayude!

y también uso mysql_upgrade -uroot -pfallido porque necesita MySQL para ejecutarse!

Lecciones aprendidas:

  • Haga una copia de seguridad de my.cnf antes de la actualización ... Y, de hecho, realice una actualización en el lugar en lugar de desinstalarla e instale la versión más reciente.
  • Haga que MySQL se ejecute para que pueda usar mysql_upgrade.
  • Lucro.
— Ronnie
fuente
1

El mismo problema para mí, pero el origen de mis problemas fue el antiguo formato de contraseña. Si bien mysql puede ser forzado a conectarse usando el formato anterior con "skip-secure-auth", mysql_upgrade no tiene esta opción. Primero debe actualizar la contraseña de root con el nuevo formato y luego puede actualizar su mysql.

— Leandro Dardini
fuente
1

Tuve el mismo problema al actualizar de 5.1 a 5.5.

Esto funcionó para mí: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Mi error probablemente fue causado por los permisos de la ruta del socket, pero no tengo tiempo para verificar que fue la causa.

— Capt
fuente
Había movido mi DataDir en algún momento, supongo que por eso necesitaba el camino hacia el zócalo
— zzapper
0

También me encontré con esto después de actualizar mi sistema de Mint 12 a Mint 15. Archivé / var / lib / mysql y lo volví a poner en su lugar después de la actualización. Me encontré con la primera mysqlcheckde comentario de user16081, y se quejó de mysql.sock.

Comencé a usar mysqld /usr/sbin/mysqld &y mysql_upgradefuncioné bien.

— Marty Vance
fuente
Es un método bastante aterrador para actualizar MySQL, pero me alegra que haya funcionado para usted.
— Aaron Copley
@ aaron-copley: en realidad no funcionó por completo. MySQL 5.5.32 ignora parcialmente muchas de mis tablas InnoDB; aparecen en SHOW TABLES, pero de lo contrario no existen. Actualmente estoy tratando de hacer que mysql-utilities funcionen, pero eso se queja de la falta de módulos de Python.
— Marty Vance
0

Me encontré con el mismo problema.
Lo resolví incluyendo -S /path/to/mysql.sock

En mi caso particular, la salida de mysql_upgrade fue:
Buscando 'mysql' como: mysql
Buscando 'mysqlcheck' como: mysqlcheck
ERROR FATAL: Actualización fallida

Eso es bastante inútil. --verbose no hizo ninguna diferencia.

Al conectarme, me decidí por el siguiente comando y funcionó de
maravilla : mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Espero eso ayude.

— bfieber
fuente
0

Me enfrenté a este problema y descubrí que,

  1. requería que se ejecutara el servicio MySQL

  2. requirió nombre de usuario y contraseña

— Sruit A.Suk
fuente
0

Encontré el mismo problema.

Resolví esto instalando una nueva base de datos mysql_install_db --user=mysqltal como se describe en los comentarios de mi rc.mysqlarchivo en / etc.

Luego pude iniciar mysql daemon y usar 'mysql' o lo que quieras conectado con el paquete mysql.

Tuve este problema en el brazo de slackware, pero supongamos que no importa en este caso.

— usuario323106
fuente
0

En mi caso, tenía algunas versiones de mysqld ejecutándose localmente que hicieron que mysql_upgrade fallara con Error: ¡Falló al recuperar la versión del servidor! Podría deberse a un acceso no autorizado. ps aux | grep mysqly asegúrese de que mysqld esté cerrado. Luego, desinstale todas las versiones, vuelva a instalar la versión correcta. Y después de eso, mysql_upgrade comenzó a funcionar.

— Laurens Bronwasser
fuente
-1

tratar 

mysql_upgrade --verbose

o tal vez incluso (o ambos)

--debug-check --debug-info
— alexus
fuente
Intenté eso, no hay información útil real, no creo |;
— Jim Rubenstein
reinició y pegó información de registro de error \; No estoy seguro de por qué seguiría repitiendo esos mismos errores una y otra vez.
— Jim Rubenstein
parece que tienes un error allí, 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existcreo que eso es lo que hace que todo falle.
— alexus
pero antes de eso, intente mysql_upgrade --version y proporcione resultados para eso.
— alexus
mysql_upgrade --versionno produce salida de versión (solo el error ERROR FATAL). mysql --versiones mysql Ver 14.14 Distrib 5.5.32, para debian-linux-gnu (x86_64) usando readline 6.2, y la versión mysqld es 5.5
— Jim Rubenstein
-3

El usuario root de MySQL se llama "admin", no root. El comando correcto es

mysql_upgrade -uadmin -p
— Marco Marsala
fuente
Esto está absolutamente mal. El usuario root en MySQL es root.
— dr01
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.