Puisqu'aucune des réponses ci-dessus n'explique réellement ce qui s'est passé, j'ai décidé d'intervenir et d'apporter plus de détails à ce problème.
Oui, la solution consiste à exécuter la commande de mise à niveau MySQL, comme suit: mysql_upgrade -u root -p --force
mais que s'est-il passé?
La cause principale de ce problème est la corruption de performance_schema
, qui peut être causée par:
- Corruption organique (volumes en kaboom, bogue moteur, problème de pilote de noyau, etc.)
- Corruption pendant le correctif mysql (il n'est pas rare que cela se produise pendant un correctif mysql, spécialement pour les mises à niveau de versions majeures)
- Un simple "drop database performance_schema" provoquera évidemment ce problème, et il présentera les mêmes symptômes que s'il était corrompu
Ce problème était peut-être présent sur votre base de données avant même le correctif, mais ce qui s'est produit sur MySQL 5.7.8 en particulier, c'est que l'indicateur a show_compatibility_56
changé sa valeur par défaut d'être transformé ON
par défaut enOFF
. Cet indicateur contrôle le comportement du moteur lors des requêtes de définition et de lecture de variables (de session et globales) sur différentes versions de MySQL.
Étant donné que MySQL 5.7+ a commencé à lire et à stocker ces variables sur performance_schema
au lieu d' activer information_schema
, cet indicateur a été introduit comme ON
pour les premières versions pour réduire le rayon de souffle de ce changement et pour permettre aux utilisateurs de connaître le changement et de s'y habituer.
OK, mais pourquoi la connexion échoue-t-elle? Parce que selon le pilote que vous utilisez (et sa configuration), il peut finir par exécuter des commandes pour chaque nouvelle connexion initiée à la base de données (comme show variables
, par exemple). Parce qu'une de ces commandes peut essayer d'accéder à un fichier corrompuperformance_schema
, la connexion entière s'interrompt avant d'être entièrement lancée.
Donc, en résumé, vous pouvez (il est impossible de le dire maintenant) avoir performance_schema
été manquant ou corrompu avant d'appliquer les correctifs. Le correctif à 5.7.8 a ensuite forcé le moteur à lire vos variables performance_schema
(au lieu de information_schema
, d'où il les lisait à cause du drapeau tourné ON
). Depuis a performance_schema
été corrompu, les connexions échouent.
La mise à niveau de MySQL est la meilleure approche, malgré le temps d'arrêt. Activer le drapeau est une option, mais il a son propre ensemble d'implications, comme cela a déjà été souligné sur ce fil.
Les deux devraient fonctionner, mais pesez les conséquences et connaissez vos choix :)
5.7.8-rc
version et une restauration à partir de la sauvegarde complète de la base de données.