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

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:

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)

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.

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`

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

Mismo problema! La solución para mí vino de http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

Brevemente: ¡el error es engañoso! ejecutar mysql_upgrade -u root -pcon el DB en línea y proporcionar la contraseña de root.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

tratar

mysql_upgrade --verbose 

o tal vez incluso (o ambos)

--debug-check --debug-info

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

mysql_upgrade -uadmin -p