La table 'performance_schema.session_variables' n'existe pas


299

Après la mise à niveau de MySQL vers 5.7.8-rc et la connexion au serveur, j'ai eu une erreur:

Table 'performance_schema.session_variables' doesn't exist

Je ne trouve aucune solution à cela. Pouvez-vous m'aider?


2
Un autre. Il semble que votre mise à niveau n'ait pas réussi. Vous pouvez envisager de refaire le processus de mise à niveau (ou) de réinstaller la 5.7.8-rcversion et une restauration à partir de la sauvegarde complète de la base de données.
Rahul

2
avez-vous exécuté mysql_upgradepour vous assurer que toute modification des tables / dbs de base a été effectuée?
Marc B

ouais, j'ai fait mysql_upgrade, je donne le dernier essai et je le réinstalle à nouveau. Si cela ne fonctionne pas, je passerai à la version 5.6
Taz

28
J'ai rencontré le même problème, pour le résoudre, je cours mysql_upgrade -u root -p --force, puis j'ai redémarré le serveur DB.
robregonm

Si la commande mysql_upgrade ne fonctionne pas, la table mysql.performance_schema est peut-être endommagée. Nous avons eu ce problème. Pour résoudre le problème, nous avons supprimé le serveur de base de données à l'aide de la commande: apt-get purge mariadb-client-10.1 mariadb-common mariadb-server-10.1. Cela a supprimé tous les fichiers binaires, de configuration et de données de la base de données. Ensuite, nous avons réinstallé le serveur de base de données et réimporté les bases de données. Après cela, le serveur de base de données a fonctionné sans problème
Nadir Latif

Réponses:


227

Le mysql_upgrade a également fonctionné pour moi:

# mysql_upgrade -u root -p --force
# systemctl restart mysqld

Cordialement, MSz.


25
J'ai eu besoin de redémarrer mysqld ( mysql.server restart, puisque j'utilise une installation homebrew sur os x), cela a donc été utile. Sinon, j'ai eu une erreur sur les variables de session ayant la mauvaise structure.
Geoffrey Wiseman

Comportement identique avec Homebrew sur OS X 10.10.5 (Yosemite). La mise à niveau corrige également un plantage dans Sequel Pro 1.1 (build 4499) lors de la tentative de chargement de la base de données.
William Turrell

4
Native table 'performance_schema'.'session_variables' has the wrong structure
stephen

8
Si vous utilisez, brew servicesvous pouvez redémarrer votre serveur avec brew services restart mysql.
Frederik Kammer du

1
Cela ne fonctionne pas pour moi, la bonne réponse est donnée par viq. seul est nécessaire pour activer la compatibilité du spectacle.
kato2

482

J'ai pu me connecter au serveur mysql après avoir exécuté la commande @robregonm suggérée:

mysql_upgrade -u root -p --force

Un redémarrage du serveur MySQL est requis.


6
Cela a bien fonctionné. Merci, je veux savoir quelle est la raison.
diguage

2
J'obtiens Access denied for user 'root'@'localhost' (using password: YES) while connecting to the MySQL servermême si j'utilise le mot de passe root correct. De l'aide?? : - /
sixty4bit

4
@ sixty4bit essayez de supprimer le -p
Mike Mellor

1
@NevilleNazerane Je ne suis pas familier avec le php facile, mais vous devriez pouvoir localiser où mysql est installé, puis juste ouvrir une invite cdm et changer le répertoire à cet emplacement. Vous devriez maintenant pouvoir exécuter la commande.
Mihai Caracostea

4
@diguage La raison en est que la mise à niveau de la version de MySQL a introduit des schémas incompatibles avec les versions pour les métadonnées internes. Pour moi, je mets à jour MySQL 5.6 vers MySQL 5.7 sur un Mac en utilisant Homebrew et le répertoire de données MySQL est inchangé, donc la nouvelle version MySQL lit les anciennes métadonnées internes mais je ne sais pas quoi faire - cette erreur que nous avons vue ici est un manifeste de cette question. Après mysql_upgradeet un redémarrage, tout a fonctionné. Voir: dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html
Devy

110
mysql -u app -p
mysql> set @@global.show_compatibility_56=ON;

selon http://bugs.mysql.com/bug.php?id=78159 a fonctionné pour moi.


1
Cela a parfaitement fonctionné pour moi! Et je n'ai pas eu à redémarrer le serveur mysql qui aurait été si lourd
anu.agg

3
Je suis désolé, c'est une solution un peu trop grande: comme utiliser un bazooka pour tirer une mouche. Ce commutateur de compatibilité a beaucoup plus d'effets, vous ne voudrez peut-être pas tous.
Tuncay Göncüoğlu

@Tuncay Göncüoğlu quels sont certains de ces effets secondaires?
katzmopolitan

@katzmopolitan Lisez ici: dev.mysql.com/doc/refman/5.7/en/… . Les changements sont principalement liés à la gestion de INFORMATION_SCHEMA (sécurité, etc.), mais il y en a plus.
Tuncay Göncüoğlu

Cela a également fonctionné pour moi. Le message d'erreur que j'ai reçu venait de mysqldump. Une fois que j'ai fait le changement suggéré, mysqldump a fonctionné. Une fois que j'ai eu le vidage, j'ai simplement changé le show_compatibility_56 en OFF.
Bryan

23

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_56changé sa valeur par défaut d'être transformé ONpar 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_schemaau lieu d' activer information_schema, cet indicateur a été introduit comme ONpour 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 :)


1
Merci. Je me demandais ce qui a causé ce problème avant de sauter et d'apporter des changements.
Ken Ingram

4

Suivez ces étapes sans -p:

  1. mysql_upgrade -u root
  2. systemctl restart mysqld

J'ai eu le même problème et ça marche!


Cela marche! Seulement systemctl restart mysqldn'a pas fonctionné.
Ninja

puis utilisezsystemctl restart mysql
BitDEVil2K16

1

En tant que question de soixante bits, si votre utilisateur racine mysql semble être mal configuré, essayez d'installer l'extension du configurateur à partir de la source officielle mysql:

https://dev.mysql.com/downloads/repo/apt/

Il vous aidera à configurer un nouveau mot de passe d'utilisateur root.

Assurez-vous de mettre à jour votre référentiel (debian / ubuntu):

apt-get update

0

Pour mon système, le problème a fini par être que j'avais toujours installé Mysql 5.6 et donc le mysql_upgrade.exe de cette installation était appelé au lieu de celui de 5.7. Accédez à C:\Program Files\MySQL\MySQL Server 5.7\binet exécutez.\mysql_upgrade.exe -u root


0

Si, lors de l'utilisation de la mysql_upgrade -u root -p --forcecommande, vous obtenez cette erreur:

Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13

ajoutez juste sudoavant la commande. Cela a fonctionné pour moi et j'ai résolu mon problème. Donc c'est: sudo mysql_upgrade -u root -p --force:)


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.