Como ninguna de las respuestas anteriores explica realmente lo que sucedió, decidí intervenir y aportar más detalles sobre este problema.
Sí, la solución es ejecutar el comando de actualización de MySQL de la siguiente manera mysql_upgrade -u root -p --force
, pero ¿qué pasó?
La causa raíz de este problema es la corrupción de performance_schema
, que puede ser causada por:
- Corrupción orgánica (volúmenes volviendo kaboom, error del motor, problema del controlador del kernel, etc.)
- Corrupción durante el parche mysql (no es extraño que esto suceda durante un parche mysql, especialmente para actualizaciones de versiones principales)
- Obviamente, una simple "caída de la base de datos performance_schema" causará este problema y presentará los mismos síntomas que si estuviera dañado
Este problema podría haber estado presente en su base de datos incluso antes del parche, pero lo que sucedió en MySQL 5.7.8 específicamente es que el indicador show_compatibility_56
cambió su valor predeterminado de ser activado ON
por defecto a OFF
. Este indicador controla cómo se comporta el motor en las consultas para configurar y leer variables (sesión y global) en varias versiones de MySQL.
Debido a que MySQL 5.7+ comenzó a leer y almacenar estas variables en performance_schema
lugar de hacerlo information_schema
, este indicador se introdujo ON
en las primeras versiones para reducir el radio de explosión de este cambio y para que los usuarios conozcan el cambio y se acostumbren.
OK, pero ¿por qué falla la conexión? Porque dependiendo del controlador que esté utilizando (y su configuración), puede terminar ejecutando comandos para cada nueva conexión iniciada en la base de datos (como show variables
, por ejemplo). Debido a que uno de estos comandos puede intentar acceder a un corrupto performance_schema
, la conexión completa se cancela antes de iniciarse por completo.
Entonces, en resumen, es posible (es imposible saberlo ahora) haber performance_schema
faltado o dañado antes de parchear. El parche a 5.7.8 luego forzó al motor a leer sus variables performance_schema
(en lugar de information_schema
, desde dónde lo estaba leyendo debido a que se activó la bandera ON
). Como performance_schema
se corrompió, las conexiones están fallando.
Ejecutar la actualización de MySQL es el mejor enfoque, a pesar del tiempo de inactividad. Activar el indicador es una opción, pero tiene sus propias implicaciones, como ya se señaló en este hilo.
Ambos deberían funcionar, pero sopesa las consecuencias y conoce tus opciones :)
5.7.8-rc
versión y restaurar desde la copia de seguridad completa de la base de datos.