Vraag `mysql_upgrade` faalt zonder dat een echte reden wordt gegeven


Ik ben bezig met upgraden van MySQL 5.1 naar 5.5, uitgevoerd mysql_upgrade en krijg deze output:

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

Eventuele ideeën over waar te zoeken naar wat er gebeurt (of niet gebeurt?), Zodat ik kan repareren wat er mis is en daadwerkelijk wordt uitgevoerd mysql_upgrade?

Bedankt!

Meer output:

# 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

Na het afsluiten mysqld --skip-grant-tables via mysqladmin shutdown en herstart mysql via service mysql start, het foutenlogboek doorloopt herhaaldelijk deze reeks fouten:

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-logboek tijdens opstarten via 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)

Zoals ik het begrijp, moeten alle problemen met de tabelstructuur / het bestaan ​​(met betrekking tot mysql-systeemtabellen) worden gecorrigeerd door mysql_upgrade :


68
2017-07-30 20:21


oorsprong


Waarschijnlijk ook niets waard, mysqld draait, met --skip-grant-tables keuze. Ik kan verbinding maken via mysql op de terminal zonder referenties, en ik krijg geen fouten via syslog of ergens anders waar ik aan kan denken om te kijken als ik wegloop mysql_upgrade - Jim Rubenstein
De MySQL Naslaggids dekt de upgrade naar 5.5 van 5.1 vrij goed. Als u alle instructies hier hebt opgevolgd, zou het het vermelden waard zijn. Als je dat niet hebt, nou ... - Aaron Copley
Als uw mysql root-gebruiker geen wachtwoord heeft, neem dan `-p` niet op in` mysql_upgrade -u root -p` - Jeferex


antwoorden:


Ik denk dat het gebruikersnaam en wachtwoord nodig heeft

mysql_upgrade -u root -p

Als ik ze niet door geef, krijg ik je foutmelding

Bewerk: dankzij de opmerkingen weet ik nu dat er andere redenen zijn, misschien minder vaak, maar het is ook het beste om u hiervan bewust te zijn

Dus je krijgt die fout wanneer

  • je hebt geen gebruikersnaam en wachtwoord doorgegeven
  • je hebt je inloggegevens doorgegeven, maar ze hadden het mis
  • de MySQL-server is niet actief
  • de permissietabellen zijn geruïneerd (dan moet je MySQL opnieuw opstarten met mysqld --skip-grant-table)
  • de tabel mysql.plugin ontbreekt (u ziet een fout daarover bij het starten van MySQL, wat suggereert om ... mysql_upgrade uit te voeren, en dat mislukt. U hebt waarschijnlijk een verouderde configuratie in my.cnf)

93
2017-08-14 10:01



Dit was precies het probleem dat ik had - waarom zou het niet gewoon kunnen zeggen "Kon authenticatie niet" of "Verbindingsfout" of zoiets? Zo boos ... - les2
Jongens, je krijgt dezelfde fout als je wachtwoord ook fout is. dus wees op de hoogte. - Yoosaf Abdulla
En u krijgt dezelfde foutmelding als de server niet actief is, ook al lijkt deze het wachtwoord te accepteren. - Raman
net als de databasetabel of het databaseformaat ook wordt verbroken, werkt het ook niet, dan moet je de daemon starten met "mysqld --skip-grant-tables" en mysql_upgrade uitvoeren in een andere terminal! - Henning
+1 hiervoor. Nog een andere reden waarom ik MySQL haat - Excalibur


Ik ben net deze precieze symptomen tegengekomen bij het upgraden van 5.5 naar 5.6, en het bleek een probleem te zijn met de bereikbaarheid van services.

Hoewel de cli MySQL-client verbinding kon maken met mijn lokale DB-instantie met alleen a -u en -p, moest ik ook -h 127.0.0.1 opgeven voor mysql_upgrade omdat het probeerde een socket-bestandsverbinding te maken en jammerlijk in de poging faalde.


9
2017-08-19 19:33



dat was precies mijn probleem omdat ik mysqd op deze manier uitvoer: mysqld --skip-grant-tables --user = mysql - Rodo


Dat lijkt een Plesk-server, bij het gebruik van Plesk is er geen root voor Mysql, maar de beheerder van Mysql heeft admin genoemd, dus deze opdracht zou moeten werken op Plesk zoals ik het eerder heb geprobeerd:

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

9
2017-10-09 08:56



Dit werkte perfect voor mij - Carlos Alberto Martínez Gadea


Zelfde probleem! De oplossing voor mij kwam van http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

In het kort: de fout is misleidend! rennen mysql_upgrade -u root -p met de DB on-line en geef het root-wachtwoord op.


5
2017-11-30 10:23





je zou kunnen proberen deze een voor een uit te voeren om te zien waar het faalt:

mysql_upgrade voert de volgende opdrachten uit om tabellen te controleren en te repareren en om de systeemtabellen te upgraden:

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

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


4
2017-07-30 21:10



Dacht daarover, maar fix_priv_tablesis een script dat wordt gegenereerd door mysql_upgrade om de Privelege-tabellen te repareren - Jim Rubenstein
goed punt, misschien probeer je gewoon de eerste mysqlcheck-regel? En probeer direct vanuit de bin-map te rennen, fwiw, /usr/bin/mysql_upgrade - user16081-JoeT


Deze vraag is ongelooflijk generiek en daar verontschuldig ik me voor.

Ik kon geen directe oorzaak en oplossing vinden voor het probleem dat ik had, dus nam ik mijn toevlucht tot het opnieuw installeren van MySQL om te zien of dat zou werken. Blijkt, opnieuw installeren deed het. Dat was een flauwe manier om het te repareren, maar het was de enige optie die ik nog had.

Veel van de andere antwoorden op deze vraag zijn problemen waar ik mee moest werken om ervoor te zorgen dat mysql_upgrade aanvankelijk werd uitgevoerd, maar om welke reden dan ook - het is mislukt tijdens het uitvoeren van enkele geautomatiseerde query's en ik kon de documentatie niet vinden waarop queries dat het werd uitgevoerd, zodat ik ze kon oplossen.


3
2017-11-30 14:00



Ja, eenmaal dat de gegevens dir van mysql is beschadigd, is er vrijwel niets dat je kunt doen - Krauser


U moet alle bestanden onder mysql-gegevens controleren. Het zou dezelfde eigenaar moeten zijn van mysql PID (mysql of _mysql). Dit gebeurt soms omdat gegevens uit het bestand worden hersteld zonder de juiste toestemming. Bijvoorbeeld als uw MySQL-gegevens onder / var / lib / mysql staan

chown -R mysql /var/lib/mysql

2
2017-11-07 00:12





Onze DBA heeft mysql versie 5.0.95 verwijderd in plaats van alleen maar naar 5.5.39 te upgraden. De deïnstallatie heeft een back-up gemaakt van de /etc/my.cnf naar /etc/my.cnf.rpmsave vervolgens verwijderd en dit heeft verhinderd dat MySQL correct kon opstarten:

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

U kunt een van de volgende dingen doen:

  • Vergelijk de my.cnf-bestanden handmatig en breng de juiste configuratie-instellingen over voor InnoDB

  • Herstel de my.cnf.rpmsave terug over het origineel (controleer eerst of er nieuwe standaardinstellingen moeten worden toegevoegd!)

  • Gebruik een diff-tool zoals vimdiff om het te vergelijken my.cnf.rpmsave naar het nieuwe my.cnf en bracht de tweaks terug die waren aangebracht in MySQL config, inclusief de InnoDB-instellingen.

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

Ik deed de laatste optie en kon toen MySQL starten:

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

en nu de mysql_upgrade werkt prima, met behulp van mysql_upgrade -uroot -p dus het vroeg me om een ​​root-wachtwoord.

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

Ik hoop dat dit helpt!

en ook gebruiken mysql_upgrade -uroot -p is mislukt omdat MySQL nodig heeft om te worden uitgevoerd!

Les geleerd:

  • Maak een back-up van my.cnf vóór de upgrade ... En voer eigenlijk een interne upgrade uit in plaats van de installatie ongedaan te maken en installeer dan de nieuwere versie.
  • Haal MySQL aan zodat je mysql_upgrade kunt gebruiken.
  • Winst.

2
2017-09-02 19:20





Hetzelfde probleem voor mij, maar de bron van mijn problemen was het oude wachtwoordformaat. Hoewel mysql kan worden gedwongen om verbinding te maken met het oude formaat met "skip-secure-auth", heeft mysql_upgrade deze optie niet. Je moet eerst het root-wachtwoord bijwerken met het nieuwe formaat en dan kun je je mysql upgraden.


1
2017-07-21 07:36