Die Tabelle 'performance_schema.session_variables' existiert nicht

299

Nach dem Upgrade von MySQL auf 5.7.8-rc und der Anmeldung am Server wurde folgende Fehlermeldung angezeigt:

Table 'performance_schema.session_variables' doesn't exist

Ich kann keine Lösung dafür finden. Kannst du helfen ?

mysql  upgrade 
— Taz
quelle
2
Noch einer. Ihr Upgrade war anscheinend nicht erfolgreich. Möglicherweise möchten Sie den Aktualisierungsvorgang erneut durchführen (oder die 5.7.8-rcVersion erneut installieren und eine vollständige Sicherung von DB wiederherstellen).
— Rahul
2
mysql_upgradeHaben Sie ausgeführt, um sicherzustellen, dass Änderungen an den Kerntabellen / Datenbank vorgenommen wurden?
— Marc B
Ja, ich habe es gemacht mysql_upgrade, ich versuche es zuletzt und installiere es erneut. Wenn es nicht funktioniert, werde ich auf Version 5.6 herunterstufen
— Taz
28
Ich habe das gleiche Problem festgestellt. Um es zu lösen, mysql_upgrade -u root -p --forcestarte ich und starte den DB-Server neu.
— Robregonm
Wenn der Befehl mysql_upgrade nicht funktioniert, ist die Tabelle mysql.performance_schema möglicherweise beschädigt. Wir hatten dieses Problem. Um das Problem zu beheben, haben wir den Datenbankserver mit dem folgenden Befehl entfernt: apt-get purge mariadb-client-10.1 mariadb-common mariadb-server-10.1. Dadurch wurden alle Datenbank-Binär-, Konfigurations- und Datendateien entfernt. Als nächstes haben wir den Datenbankserver neu installiert und die Datenbanken zurück importiert. Danach lief der Datenbankserver ohne Probleme
— Nadir Latif

Antworten:

227

Das mysql_upgrade hat auch für mich funktioniert:

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

Grüße, MSz.

— Marcin Sz
quelle
25
Ich musste mysqld neu starten ( mysql.server restartda ich eine Homebrew-Installation auf OS X verwende), daher war dies hilfreich. Ansonsten habe ich eine Fehlermeldung erhalten, dass session_variables die falsche Struktur haben.
— Geoffrey Wiseman
Identisches Verhalten mit Homebrew unter OS X 10.10.5 (Yosemite). Durch das Upgrade wird auch ein Absturz in Sequel Pro 1.1 (Build 4499) behoben, wenn versucht wird, die Datenbank zu laden.
— William Turrell
4
Native table 'performance_schema'.'session_variables' has the wrong structure
— Stephen
8
Wenn Sie verwenden brew services, können Sie Ihren Server mit neu starten brew services restart mysql.
— Frederik Kammer
1
Das funktioniert bei mir nicht, die richtige Antwort gibt viq. Es wird nur benötigt, um die Showkompatibilität zu aktivieren.
— Kato2
482

Ich konnte mich am MySQL-Server anmelden, nachdem ich den Befehl @robregonm ausgeführt hatte:

mysql_upgrade -u root -p --force

Ein Neustart des MySQL-Servers ist erforderlich.

— Mihai Caracostea
quelle
6
Das hat gut funktioniert. Danke. Ich möchte wissen, was der Grund ist.
— Diguage
2
Ich bekomme, Access denied for user 'root'@'localhost' (using password: YES) while connecting to the MySQL serverobwohl ich das richtige Root-Passwort verwende. Irgendeine Hilfe?? : - /
— sixty4bit
4
@ sechzig4bit versuchen, die -p zu entfernen
— Mike Mellor
1
@NevilleNazerane Ich bin nicht mit einfachem PHP vertraut, aber Sie sollten in der Lage sein zu finden, wo MySQL installiert wird, und dann einfach eine CDM-Eingabeaufforderung öffnen und das Verzeichnis an diesen Speicherort ändern. Jetzt sollten Sie den Befehl ausführen können.
— Mihai Caracostea
4
@diguage Der Grund dafür ist, dass durch das Versions-Upgrade von MySQL inkompatible Schemata für interne Metadaten eingeführt wurden. Für mich aktualisiere ich MySQL 5.6 auf einem Mac mit Homebrew auf MySQL 5.7 und das MySQL-Datenverzeichnis war unverändert, sodass die neue Version MySQL die alten internen Metadaten las, aber nicht weiß, was zu tun ist - dieser Fehler, den wir hier gesehen haben, ist ein Manifest dieses Problems. Nach mysql_upgradeund einem Neustart funktionierte alles. Siehe: dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html
— Devy
110 
mysql -u app -p
mysql> set @@global.show_compatibility_56=ON;

gemäß http://bugs.mysql.com/bug.php?id=78159 hat für mich gearbeitet.

— viq
quelle
1
Das hat bei mir perfekt funktioniert! Und ich musste den MySQL-Server nicht neu starten, was so umständlich gewesen wäre
— anu.agg
3
Es tut mir leid, das ist eine etwas übergroße Lösung: wie mit einer Panzerfaust, um eine Fliege zu schießen. Dieser Kompatibilitätsschalter hat viel mehr Effekte, möglicherweise möchten Sie nicht alle.
— Tuncay Göncüoğlu
@Tuncay Göncüoğlu Was sind einige dieser Nebenwirkungen?
— Katzmopolitan
@katzmopolitan Lesen Sie hier: dev.mysql.com/doc/refman/5.7/en/… . Die Änderungen beziehen sich hauptsächlich auf die Behandlung von INFORMATION_SCHEMA (Sicherheit usw.), es gibt jedoch noch weitere.
— Tuncay Göncüoğlu
Das hat auch bei mir funktioniert. Die Fehlermeldung, die ich erhielt, war von mysqldump. Sobald ich die vorgeschlagene Änderung vorgenommen hatte, funktionierte mysqldump. Sobald ich den Dump hatte, änderte ich einfach die show_compatibility_56 wieder auf OFF.
— Bryan
23

Da keine der obigen Antworten tatsächlich erklärt, was passiert ist, habe ich mich entschlossen, mich zu melden und weitere Details zu diesem Thema zu bringen.

Ja, die Lösung besteht darin, den Befehl MySQL Upgrade wie folgt auszuführen: mysql_upgrade -u root -p --force Aber was ist passiert?

Die Hauptursache für dieses Problem ist die Beschädigung von performance_schema, die verursacht werden kann durch:

  • Organische Korruption (Volumes gehen Kaboom, Engine Bug, Kernel Treiber Problem usw.)
  • Beschädigung während des MySQL-Patches (es ist nicht ungewöhnlich, dass dies während eines MySQL-Patches passiert, insbesondere bei größeren Versions-Upgrades)
  • Ein einfaches "drop database performance_schema" verursacht offensichtlich dieses Problem und zeigt dieselben Symptome, als ob es beschädigt wäre

Dieses Problem war möglicherweise bereits vor dem Patch in Ihrer Datenbank vorhanden. In MySQL 5.7.8 wurde jedoch festgestellt, dass das Flag show_compatibility_56seinen Standardwert ONvon "Standard" auf "Standard" geändert hatOFF . Dieses Flag steuert, wie sich die Engine bei Abfragen zum Festlegen und Lesen von Variablen (Sitzung und global) in verschiedenen MySQL-Versionen verhält.

Da MySQL 5.7+ zu lesen und speichern begonnen , diese Variablen auf performance_schemastatt auf information_schemawurde, dieses Flag als eingeführt ONfür die ersten Veröffentlichungen der Explosionsradius dieser Änderung zu reduzieren und Nutzer über die Änderung zu informieren und sich daran gewöhnen.

OK, aber warum schlägt die Verbindung fehl? Abhängig vom verwendeten Treiber (und seiner Konfiguration) werden möglicherweise Befehle für jede neue Verbindung ausgeführt, die zur Datenbank initiiert wird ( show variablesz. B.). Weil einer dieser Befehle versuchen kann, auf einen beschädigten zuzugreifenperformance_schema Verbindung , wird die gesamte Verbindung abgebrochen, bevor sie vollständig initiiert wird.

Zusammenfassend lässt sich sagen, dass Sie möglicherweise (es ist derzeit nicht zu sagen) performance_schemavor dem Patchen entweder fehlten oder beschädigt waren. Der Patch auf 5.7.8 zwang die Engine dann dazu, Ihre Variablen auszulesen performance_schema(anstatt von dort information_schema, wo sie aufgrund des gedrehten Flags gelesen wurde ON). Da performance_schemawurde beschädigt, schlagen die Verbindungen fehl.

Das Ausführen eines MySQL-Upgrades ist trotz der Ausfallzeit der beste Ansatz. Das Aktivieren des Flags ist eine Option, hat jedoch eine Reihe von Auswirkungen, auf die bereits in diesem Thread hingewiesen wurde.

Beide sollten funktionieren, aber die Konsequenzen abwägen und Ihre Entscheidungen kennen :)

— Marcello Grechi Lins
quelle
1
Vielen Dank. Ich habe mich gefragt, was dieses Problem verursacht hat, bevor ich darauf gesprungen bin und Änderungen vorgenommen habe.
— Ken Ingram
4

Befolgen Sie diese Schritte ohne -p:

  1. mysql_upgrade -u root
  2. systemctl restart mysqld

Ich hatte das gleiche Problem und es funktioniert!

— Pranay Srivastava
quelle
Das funktioniert! Nur systemctl restart mysqldhat nicht funktioniert.
— Ninja
dann benutzesystemctl restart mysql
— BitDEVil2K16
1

Wenn Ihr MySQL-Root-Benutzer als 60-Bit-Frage falsch konfiguriert zu sein scheint, versuchen Sie, die Konfigurator-Erweiterung aus der offiziellen MySQL-Quelle zu installieren:

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

Es wird Ihnen helfen, ein neues Root-Benutzerpasswort einzurichten.

Stellen Sie sicher, dass Sie Ihr Repository (debian / ubuntu) aktualisieren:

apt-get update
— Matteus Barbosa
quelle
0

Für mein System bestand das Problem darin, dass ich immer noch MySQL 5.6 installiert hatte und daher die Datei mysql_upgrade.exe aus dieser Installation anstelle der für 5.7 aufgerufen wurde. Navigieren Sie zu C:\Program Files\MySQL\MySQL Server 5.7\binund führen Sie es aus.\mysql_upgrade.exe -u root

— Alan
quelle
0

Wenn Sie mit dem mysql_upgrade -u root -p --forceBefehl diesen Fehler erhalten:

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

Fügen Sie einfach das sudovor dem Befehl hinzu. Das hat bei mir funktioniert und ich habe mein Problem gelöst. Also ist es: sudo mysql_upgrade -u root -p --force:)

— Aleksandar
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.