it-swarm.com.de

`mysql_upgrade` schlägt ohne wirklichen Grund fehl

Ich aktualisiere von MySQL 5.1 auf 5.5, führe mysql_upgrade Aus und erhalte diese Ausgabe:

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

Irgendwelche Ideen, wo man suchen soll, was passiert (oder nicht passiert?), Damit ich das Problem beheben und tatsächlich mysql_upgrade Ausführen kann?

Vielen Dank!

Mehr Ausgabe:

# 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 von mysqld --skip-grant-tables Über mysqladmin shutdown Und dem Neustart von mysql über service mysql start Durchläuft das Fehlerprotokoll diese Fehler 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-Protokoll 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)

Soweit ich weiß, sollten alle Probleme mit der Tabellenstruktur/-existenz (in Bezug auf MySQL-Systemtabellen) durch Ausführen von mysql_upgrade Korrigiert werden:

70
Jim Rubenstein

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

Ich konnte keine direkte Ursache und Lösung für das Problem finden, das ich hatte, und habe MySQL neu installiert, um zu prüfen, ob dies funktionieren würde. Es stellte sich heraus, dass die Neuinstallation den Trick getan 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 sind Probleme, die ich lösen musste, damit mysql_upgrade anfänglich ausgeführt wurde, aber aus welchem ​​Grund auch immer - es schlug fehl, da versucht wurde, einige automatisierte Abfragen auszuführen, und ich konnte die Dokumentation nicht finden, zu der Abfragen, die ausgeführt wurden, damit ich sie beheben konnte.

3
Jim Rubenstein

Ich denke, dass es Benutzername und Passwort braucht

mysql_upgrade -u root -p

Wenn ich sie nicht bestanden habe, erhalte ich Ihren Fehler

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

Sie erhalten also diesen Fehler, wenn

  • sie haben Benutzername und Passwort nicht übergeben
  • sie haben Ihre Anmeldeinformationen weitergegeben, aber sie waren falsch
  • der MySQL-Server läuft nicht
  • die Tabellen der Berechtigungen sind ruiniert (dann müssen Sie MySQL mit mysqld --skip-grant-table neu starten.)
  • die Tabelle mysql.plugin fehlt (beim Starten von MySQL wird ein Fehler angezeigt, der darauf hindeutet, ... mysql_upgrade auszuführen, und dies schlägt fehl. Sie haben wahrscheinlich eine veraltete Konfiguration in my.cnf).
95
Riccardo Galli

Das scheint ein Plesk-Server zu sein. Wenn Sie Plesk verwenden, gibt es kein Stammverzeichnis für MySQL, aber der Administrator von MySQL nennt sich admin. Daher sollte dieser Befehl auf Plesk so funktionieren, wie ich es zuvor versucht habe:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
9
linuxman1

Ich habe gerade diese genauen Symptome beim Upgrade von 5.5 auf 5.6 festgestellt, und es stellte sich heraus, dass es sich um ein Problem mit der Erreichbarkeit von Diensten handelt.

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

9
Aubrey Falconer

Gleicher Fehler! Die Lösung für mich kam von http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

Kurz gesagt: Der Fehler ist irreführend! Lauf mysql_upgrade -u root -p mit der DB online und geben Sie das Root-Passwort ein.

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

5
user16081-JoeT

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

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

Unser DBA hat mysql Version 5.0.95 deinstalliert, anstatt nur auf 5.5.39 zu aktualisieren. Bei der Deinstallation wurde /etc/my.cnf Auf /etc/my.cnf.rpmsave Gesichert und dann entfernt. Dadurch wurde verhindert, dass MySQL ordnungsgemäß 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 Folgendes tun:

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

  • Stellen Sie den my.cnf.rpmsave Wieder über dem Original wieder her (überprüfen Sie zuerst, ob neue Standardeinstellungen vorhanden sind, die Sie hinzufügen sollten!).

  • Verwenden Sie ein Diff-Tool wie vimdiff, um my.cnf.rpmsave Mit dem neuen my.cnf Zu vergleichen und die an der MySQL-Konfiguration vorgenommenen Änderungen, einschließlich der InnoDB-Einstellungen, wieder aufzunehmen.

    [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 funktioniert mysql_upgrade einwandfrei mit mysql_upgrade -uroot -p, sodass 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 von mysql_upgrade -uroot -p ist fehlgeschlagen, da MySQL ausgeführt werden muss!

Gewonnene Erkenntnisse:

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

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.

1
Capt

Das gleiche Problem für mich, aber die Ursache 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 können dann Ihre MySQL aktualisieren.

1
Leandro Dardini

In meinem Fall wurden einige Versionen von mysqld lokal ausgeführt, wodurch mysql_upgrade mit fehlschlug. Fehler: Fehler beim Abrufen der Serverversion! Könnte an unbefugtem Zugriff liegen. ps aux | grep mysql und stellen Sie sicher, dass mysqld vollständig heruntergefahren ist. Dann brauen alle Version deinstallieren, die richtige Version neu installieren. Und danach fing mysql_upgrade an zu arbeiten.

0

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

In meinem speziellen Fall war die Ausgabe von mysql_upgrade:
Auf der Suche nach 'mysql' als: mysql
Auf der Suche nach 'mysqlcheck' als: mysqlcheck
FATAL ERROR: Upgrade fehlgeschlagen

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

Beim Einstecken habe ich mich für den folgenden Befehl entschieden und es hat wie ein Zauber funktioniert:
Mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Ich hoffe es hilft.

0
bfieber

Ich stand vor diesem Problem und fand heraus, dass

  1. der MySQL-Dienst musste ausgeführt werden

  2. es waren Benutzername und Passwort erforderlich

0
Sruit A.Suk

Ich bin auf das gleiche Problem gestoßen.

Ich habe dieses Problem gelöst, indem ich eine neue Datenbank mit mysql_install_db --user=mysql Installiert habe, wie in den Kommentaren meiner rc.mysql - Datei in/etc. Beschrieben.

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

Ich hatte dieses Problem am Slackware-Arm, aber nehme an, es spielt in diesem Fall keine Rolle.

0
user323106

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 das erste mysqlcheck aus dem Kommentar von user16081 ausgeführt und es hat sich über mysql.sock beschwert.

Ich habe mysqld mit /usr/sbin/mysqld & Gestartet und mysql_upgrade Ist einwandfrei gelaufen.

0
Marty Vance