mysql_upgrade schlägt ohne Angabe von Gründen fehl

70

Ich aktualisiere von MySQL 5.1 auf 5.5, starte mysql_upgradeund erhalte diese Ausgabe:

# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

Irgendwelche Ideen, wo Sie nachsehen können, was gerade passiert (oder was nicht?), Damit ich das Problem beheben und tatsächlich ausführen kann mysql_upgrade?

Vielen Dank!

Mehr Leistung:

# 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

Nach dem Herunterfahren mysqld --skip-grant-tablesüber mysqladmin shutdownund dem Neustart von mysql über service mysql startdurchläuft das Fehlerprotokoll diese Fehlermenge immer wieder:

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

MySQL-Log beim Start über 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)

So wie ich es verstehe, sollten alle Probleme mit der Tabellenstruktur / -existenz (im Zusammenhang mit MySQL-Systemtabellen) behoben werden, indem Folgendes ausgeführt wird mysql_upgrade:

mysql  mysql5.5 
— Jim Rubenstein
quelle
Auch wahrscheinlich nichts wert, mysqldläuft, mit --skip-grant-tablesOption. Ich kann über mysqldas Terminal ohne Anmeldeinformationen eine Verbindung herstellen, und ich erhalte keine Fehler über Syslog oder irgendwo anders, wo ich nachsehen kann, wenn ich laufemysql_upgrade
— Jim Rubenstein
Das MySQL-Referenzhandbuch behandelt das Upgrade von 5.1 auf 5.5 ziemlich gut. Wenn Sie alle Anweisungen hier befolgt haben, wäre es erwähnenswert. Wenn Sie nicht haben, gut ...
— Aaron Copley
Wenn Ihr MySQL-Root-Benutzer kein Kennwort hat, geben Sie "-p" nicht in "mysql_upgrade -u root -p"
— Jeferex

Antworten:

95

Ich denke, dass es Benutzername und Passwort benötigt

mysql_upgrade -u root -p

Wenn ich sie nicht bestehe, bekomme ich deine Fehlermeldung

Bearbeiten : Dank der Kommentare weiß ich jetzt, dass es andere Gründe gibt, vielleicht weniger häufig, aber es ist am besten, sie auch zu beachten

Sie erhalten diesen Fehler also, wenn

  • Sie haben Benutzername und Passwort nicht übergeben
  • Sie haben Ihre Anmeldeinformationen übergeben, aber sie waren falsch
  • Der MySQL Server läuft nicht
  • die Berechtigungstabellen sind ruiniert (dann müssen Sie MySQL mit neu starten mysqld --skip-grant-table)
  • Die Tabelle mysql.plugin fehlt (beim Starten von MySQL wird ein Fehler angezeigt, der darauf hindeutet, dass ... mysql_upgrade ausgeführt wird, und der fehlschlägt. Möglicherweise ist die Konfiguration in my.cnf veraltet.)
— Riccardo Galli
quelle
23
Dies war genau das Problem, das ich hatte - warum zum Teufel konnte es nicht einfach "Konnte nicht authentifizieren" oder "Verbindungsfehler" oder so etwas sagen? So wütend ...
— les2
3
Leute, Sie bekommen den gleichen Fehler, wenn auch Ihr Passwort falsch ist. also sei informiert.
— Yoosaf Abdulla
3
Und Sie erhalten den gleichen Fehler, wenn der Server nicht ausgeführt wird, obwohl er das Kennwort zu akzeptieren scheint.
— Raman
1
Nur wenn die Datenbanktabelle oder das Datenbankformat beschädigt ist, funktioniert es auch nicht. Dann müssen Sie den Dämon mit "mysqld --skip-grant-tables" starten und mysql_upgrade in einem anderen Terminal ausführen!
— Henning
+1 dafür. Noch ein Grund, warum ich MySQL hasse
— Excalibur
9

Ich bin beim Upgrade von 5.5 auf 5.6 auf genau diese Symptome gestoßen, und es stellte sich heraus, dass es sich um ein Problem mit der Erreichbarkeit von Diensten handelte.

Obwohl der CLI-MySQL-Client mit nur -u und -p eine Verbindung zu meiner lokalen DB-Instanz herstellen konnte, musste ich -h 127.0.0.1 für mysql_upgrade angeben, da er versuchte, eine Socket-Dateiverbindung herzustellen, und der Versuch scheiterte kläglich.

— Aubrey Falconer
quelle
Das war genau mein Problem, weil ich mysqd so ausführe: mysqld --skip-grant-tables --user = mysql
— Rodo
9

Dies scheint ein Plesk-Server zu sein. Wenn Sie Plesk verwenden, gibt es keinen Root für Mysql, aber der Administrator von Mysql heißt admin. Daher sollte dieser Befehl auf Plesk funktionieren, wie ich es zuvor versucht habe:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
quelle
Dies funktionierte perfekt für mich
— xarlymg89
5

Sie können versuchen, diese nacheinander auszuführen, um festzustellen, wo dies fehlschlägt:

mysql_upgrade führt die folgenden Befehle aus, um Tabellen zu überprüfen und zu reparieren und die Systemtabellen zu aktualisieren: 

mysqlcheck --all-databases --check-upgrade --auto-repair  
mysql < fix_priv_tables  
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

von http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

— user16081-JoeT
quelle
1
Dachte darüber nach, ist aber fix_priv_tablesein Skript, das generiert wird, mysql_upgradeum die Privileg-Tabellen zu reparieren
— Jim Rubenstein
guter Punkt, vielleicht versuchen Sie es einfach mit der ersten mysqlcheck-Zeile? Und versuchen Sie es direkt aus dem Ordner bin, fwiw,/usr/bin/mysql_upgrade
— user16081-JoeT
3

Diese Frage ist unglaublich allgemein und ich entschuldige mich dafür.

Ich konnte keine direkte Ursache und Lösung für das Problem finden, also habe ich MySQL neu installiert, um zu sehen, ob das funktionieren würde. Es stellte sich heraus, dass die Neuinstallation den Trick gemacht hat. Das war ein lahmer Weg, um das Problem zu beheben, aber es war die einzige Option, die ich noch hatte.

Viele der anderen Antworten auf diese Frage waren Probleme, die ich durcharbeiten musste, um mysql_upgrade zunächst zum Laufen zu bringen, aber aus irgendeinem Grund - es schlug fehl, weil versucht wurde, einige automatische Abfragen auszuführen, und ich konnte die Dokumentation nicht finden, auf der Abfragen, die ausgeführt wurden, damit ich sie beheben konnte.

— Jim Rubenstein
quelle
Ja, sobald das Datenverzeichnis von MySQL beschädigt wurde, können Sie so gut wie nichts mehr tun
— Krauser
2

Sie müssen die Berechtigung aller Dateien unter MySQL-Daten überprüfen. Es sollte derselbe Eigentümer von mysql PID sein (mysql oder _mysql). Dies kann vorkommen, wenn Daten ohne entsprechende Erlaubnis aus einer Datei wiederhergestellt werden. Zum Beispiel, wenn sich Ihre MySQL-Daten unter / var / lib / mysql befinden

chown -R mysql /var/lib/mysql
— asofyan
quelle
2

Unser DBA hat mysql Version 5.0.95 deinstalliert, anstatt nur auf 5.5.39 zu aktualisieren. Die Deinstallation sicherte das, /etc/my.cnfum es /etc/my.cnf.rpmsavedann zu entfernen, und dies verhinderte, dass MySQL richtig gestartet wurde:

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

Sie können eine der folgenden Aktionen ausführen:

  • Vergleichen Sie die my.cnf-Dateien manuell und nehmen Sie die entsprechenden Konfigurationseinstellungen für InnoDB vor

  • Stellen Sie die my.cnf.rpmsaveRückseite über dem Original wieder her (suchen Sie zuerst nach neuen Standardeinstellungen, die Sie hinzufügen sollten!)

  • Verwenden Sie ein Diff-Tool vimdiff, um das my.cnf.rpmsavemit dem neuen zu vergleichen my.cnfund die Änderungen, die an der MySQL-Konfiguration vorgenommen wurden, einschließlich der InnoDB-Einstellungen, rückgängig zu machen.

    [root]# vimdiff /etc/my.cnf /etc/my.cnf.rpmsave

Ich habe die letzte Option gewählt und konnte dann MySQL starten:

root]# service mysqld start
Starting mysqld:                                           [  OK  ]

und jetzt mysql_upgradefunktioniert das einwandfrei, mysql_upgrade -uroot -pso dass ich zur Eingabe des root-Passworts aufgefordert wurde.

[root]# mysql_upgrade -uroot -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
....

Hoffe das hilft!

und auch die Verwendung ist mysql_upgrade -uroot -pfehlgeschlagen, da MySQL zum Laufen benötigt wird!

Gewonnene Erkenntnisse:

  • Sichern Sie my.cnf vor dem Upgrade ... und führen Sie tatsächlich ein direktes Upgrade durch, anstatt die neuere Version zu deinstallieren und anschließend zu installieren.
  • Starten Sie MySQL, damit Sie mysql_upgrade verwenden können.
  • Profitieren.
— Ronnie
quelle
1

Das gleiche Problem für mich, aber die Quelle meiner Probleme war das alte Passwortformat. Während mysql gezwungen werden kann, eine Verbindung im alten Format mit "skip-secure-auth" herzustellen, hat mysql_upgrade diese Option nicht. Sie müssen zuerst das root-Passwort mit dem neuen Format aktualisieren und dann können Sie Ihr mysql aktualisieren.

— Leandro Dardini
quelle
1

Hatte das gleiche Problem beim Upgrade von 5.1 auf 5.5.

Das hat bei mir funktioniert: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Mein Fehler wurde wahrscheinlich durch Berechtigungen für den Socket-Pfad verursacht, aber ich habe nicht die Zeit, um zu überprüfen, ob dies die Ursache war.

— Capt
quelle
Ich hatte irgendwann mein DataDir verschoben, ich glaube, deshalb brauchte ich den Pfad zum Socket
— zzapper
0

Ich bin auch darauf gestoßen, nachdem ich mein System von Mint 12 auf Mint 15 aktualisiert hatte. Ich hatte / var / lib / mysql archiviert und nach dem Upgrade wieder installiert. Ich habe den ersten mysqlcheckKommentar von user16081 gelesen und mich über mysql.sock beschwert.

Ich habe mysqld mit gestartet /usr/sbin/mysqld &und bin gut mysql_upgradegelaufen.

— Marty Vance
quelle
Das ist eine ziemlich beängstigende Methode, um MySQL zu aktualisieren, aber ich bin froh, dass es für Sie funktioniert hat.
— Aaron Copley
@ Aaron-Copley: Eigentlich hat es nicht ganz funktioniert. In MySQL 5.5.32 werden viele meiner InnoDB-Tabellen teilweise ignoriert. sie erscheinen in SHOW TABLES, existieren aber sonst nicht. Ich versuche gerade, mysql-utilities zum Laufen zu bringen, aber das beklagt sich über fehlende Python-Module.
— Marty Vance
0

Ich bin auf dasselbe Problem gestoßen.
Ich habe es gelöst, indem ich -S /path/to/mysql.sock mit einbezogen habe

In meinem speziellen Fall lautete die Ausgabe von mysql_upgrade wie folgt
:
Suchen nach 'mysql' als: mysql Suchen nach 'mysqlcheck' als: mysqlcheck
FATAL ERROR: Upgrade fehlgeschlagen

Das ist ziemlich nutzlos. --verbose machte keinen Unterschied.

Ich habe mich für den folgenden Befehl entschieden und er hat wie ein Zauber
funktioniert : mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Ich hoffe es hilft.

— bfieber
quelle
0

Ich war mit diesem Problem konfrontiert und fand heraus, dass

  1. Es war erforderlich, dass MySQL Service ausgeführt wurde

  2. dazu sind Benutzername und Passwort erforderlich

— Sruit A.Suk
quelle
0

Ich bin auf dasselbe Problem gestoßen.

Ich habe dieses Problem gelöst, indem ich eine neue Datenbank installiert habe, mysql_install_db --user=mysqlwie in den Kommentaren meiner rc.mysqlDatei in / etc. Beschrieben .

Dann konnte ich den mysql-Daemon starten und 'mysql' verwenden oder was auch immer Sie mit dem mysql-Paket verbinden möchten.

Ich hatte dieses Problem mit dem Slackware-Arm, aber in diesem Fall spielt es keine Rolle.

— user323106
quelle
0

In meinem Fall liefen einige Versionen von mysqld lokal, wodurch mysql_upgrade mit dem Fehler fehlschlug : Fehler beim Abrufen der Serverversion ! Könnte an nicht autorisiertem Zugriff liegen. ps aux | grep mysqlund stellen Sie sicher, dass mysqld alle heruntergefahren ist. Dann deinstalliere alle Versionen und installiere die richtige Version neu. Und danach fing mysql_upgrade an zu arbeiten.

— Laurens Bronwasser
quelle
-1

Versuchen 

mysql_upgrade --verbose

oder vielleicht sogar (oder beides)

--debug-check --debug-info
— alexus
quelle
Versucht diese, keine wirklich nützlichen Informationen, glaube ich nicht |;
— Jim Rubenstein
neu gestartet und einige Fehlerprotokollinformationen eingefügt \; Ich bin mir nicht sicher, warum es immer wieder dieselben Fehler durchlaufen würde.
— Jim Rubenstein
Es scheint, als ob Sie dort einen Fehler haben - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existich denke, das ist der Grund, warum die ganze Sache fehlschlägt.
— Alexus
aber vorher versuchen Sie mysql_upgrade --version und geben Sie die Ausgabe dafür aus.
— Alexus
mysql_upgrade --versionerzeugt keine Versionsausgabe (nur den Fehler FATAL ERROR). mysql --versionist mysql Ver 14.14 Distrib 5.5.32, für debian-linux-gnu (x86_64) mit readline 6.2, und mysqld version ist 5.5
— Jim Rubenstein
-3

Der Root-Benutzer für MySQL heißt "admin", nicht root. Der richtige Befehl ist

mysql_upgrade -uadmin -p
— Marco Marsala
quelle
Das ist absolut falsch. Der root-Benutzer in MySQL ist root.
— dr01
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.