`mysql_upgrade` non riesce senza una vera ragione fornita

70

Sto eseguendo l'aggiornamento da MySQL 5.1 a 5.5, eseguendo mysql_upgradee ottenendo questo output:

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

Qualche idea su dove cercare cosa sta succedendo (o, non sta succedendo?) In modo che io possa correggere ciò che è sbagliato e effettivamente correre mysql_upgrade?

Grazie!

Più 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

Dopo l'arresto mysqld --skip-grant-tablesvia mysqladmin shutdowne riavviare mysql via service mysql start, il log degli errori loop attraverso questa serie di errori più e più volte:

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

Registro MySQL durante l'avvio tramite 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)

A quanto ho capito, tutti i problemi di struttura / esistenza della tabella (in relazione alle tabelle di sistema mysql) devono essere corretti eseguendo mysql_upgrade:

mysql  mysql5.5 
— Jim Rubenstein
fonte
Probabilmente non vale nulla, mysqldè in esecuzione, con --skip-grant-tablesopzione. Posso collegarmi mysqlsul terminale senza credenziali e non ricevo errori tramite syslog o in qualsiasi altro posto in cui riesco a pensare di guardare quando corromysql_upgrade
— Jim Rubenstein
Il Manuale di riferimento di MySQL copre abbastanza bene l'aggiornamento alla versione 5.5 da 5.1. Se hai seguito tutte le istruzioni qui, varrebbe la pena menzionarle. Se non lo hai fatto, beh ...
— Aaron Copley,
Se il tuo utente root mysql non ha una password, non includere `-p` in` mysql_upgrade -u root -p`
— Jeferex

Risposte:

95

Penso che abbia bisogno di username e password

mysql_upgrade -u root -p

Se non li passo, ricevo il tuo errore

Modifica : grazie ai commenti ora so che ci sono altri motivi, forse meno frequenti, ma è meglio esserne consapevoli

Quindi ricevi questo errore quando

  • non hai passato username e password
  • hai superato le tue credenziali, ma erano sbagliate
  • il server MySQL non è in esecuzione
  • le tabelle delle autorizzazioni sono rovinate (quindi è necessario riavviare MySQL con mysqld --skip-grant-table)
  • manca la tabella mysql.plugin (quando si avvia MySQL si vedrà un errore che suggerisce di eseguire ... mysql_upgrade e che fallisce. Probabilmente hai una configurazione obsoleta in my.cnf)
— Riccardo Galli
fonte
23
Questo era esattamente il problema che avevo - perché diavolo non poteva semplicemente dire "Impossibile autenticare" o "Errore di connessione" o qualcosa del genere? Così arrabbiato ...
— les2
3
Ragazzi, si ottiene lo stesso errore anche se la password è errata. quindi essere informato.
— Yoosaf Abdulla,
3
E ottieni lo stesso errore se il server non è in esecuzione, anche se sembra accettare la password.
— Raman,
1
proprio quando anche la tabella del database o il formato del database sono rotti, non funziona neanche, quindi è necessario avviare il demone con "mysqld --skip-grant-tables" ed eseguire mysql_upgrade in un altro terminale!
— Henning,
+1 per questo. Ancora un altro motivo per cui odio MySQL
— Excalibur,
9

Ho appena riscontrato questi sintomi precisi durante l'aggiornamento da 5.5 a 5.6 e si è rivelato un problema di raggiungibilità del servizio.

Anche se il client cli MySQL poteva connettersi alla mia istanza DB locale con solo un -u e -p forniti, avevo anche bisogno di specificare -h 127.0.0.1 per mysql_upgrade poiché stava tentando una connessione al file socket e fallendo miseramente nel tentativo.

— Aubrey Falconer
fonte
quello era esattamente il mio problema perché eseguivo mysqd in questo modo: mysqld --skip-grant-tables --user = mysql
— Rodo
9

Sembra un server Plesk, quando si usa Plesk non c'è root per Mysql, ma l'amministratore di Mysql ha chiamato admin, quindi questo comando dovrebbe funzionare su Plesk come ho provato prima:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
fonte
Questo ha funzionato perfettamente per me
— xarlymg89
5

potresti provare a eseguirli uno per uno per vedere dove falliscono:

mysql_upgrade esegue i seguenti comandi per controllare e riparare le tabelle e aggiornare le tabelle di sistema: 

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

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

— user16081-Joët
fonte
1
Ci ho pensato, ma fix_priv_tablesè uno script generato da mysql_upgradeper sistemare le tabelle dei privilegi
— Jim Rubenstein,
buon punto, forse prova solo la prima linea mysqlcheck? E prova a correre direttamente dalla cartella bin, prima,/usr/bin/mysql_upgrade
— user16081-JoeT
3

Questa domanda è incredibilmente generica e mi scuso per questo.

Non sono riuscito a trovare una causa diretta e una soluzione al problema che stavo riscontrando, quindi ho fatto ricorso alla reinstallazione di MySQL per vedere se avrebbe funzionato. Risulta, reinstallazione ha fatto il trucco. Era un modo scadente per risolverlo, ma era l'unica opzione che mi era rimasta.

Molte delle altre risposte a questa domanda sono problemi che ho dovuto affrontare per avviare inizialmente mysql_upgrade, ma per qualsiasi motivo - non è riuscito in quanto stava cercando di eseguire alcune query automatizzate e non sono riuscito a trovare la documentazione su cui interroga che era in esecuzione per consentirmi di risolverli.

— Jim Rubenstein
fonte
Sì, una volta che la directory dei dati di mysql è stata corrotta, non c'è praticamente nulla che tu possa fare
— Krauser,
2

È necessario controllare l'autorizzazione per tutti i file in dati mysql. Dovrebbe essere lo stesso proprietario di mysql PID (mysql o _mysql). Questo a volte accade perché ripristina i dati dal file senza l'autorizzazione appropriata. Ad esempio se i tuoi dati mysql sono in / var / lib / mysql

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

Il nostro DBA ha disinstallato mysql versione 5.0.95 invece di eseguire l'aggiornamento a 5.5.39. La disinstallazione ha eseguito il backup di /etc/my.cnfper /etc/my.cnf.rpmsavepoi rimuoverlo e ciò ha impedito a MySQL di avviarsi correttamente:

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

Puoi eseguire una delle seguenti operazioni:

  • Confronta i file my.cnf manualmente e porta le impostazioni di configurazione appropriate per InnoDB

  • Ripristina il my.cnf.rpmsaveretro dell'originale (controlla prima le eventuali nuove impostazioni predefinite che dovresti aggiungere!)

  • Usa uno strumento diff come vimdiffconfrontare il my.cnf.rpmsavenuovo con il nuovo my.cnfe riportato sulle modifiche apportate alla configurazione di MySQL, comprese le impostazioni di InnoDB.

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

Ho fatto l'ultima opzione, quindi sono stato in grado di avviare MySQL:

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

e ora mysql_upgradefunziona benissimo, usando mysql_upgrade -uroot -pcosì mi ha richiesto la password di root.

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

Spero che sia di aiuto!

e anche l'uso mysql_upgrade -uroot -pfallito perché ha bisogno di MySQL per funzionare!

Lezioni imparate:

  • Esegui il backup di my.cnf prima dell'aggiornamento ... Effettivamente esegui un aggiornamento sul posto anziché disinstallarlo, quindi installa la versione più recente.
  • Avvia MySQL in modo da poter usare mysql_upgrade.
  • Profitto.
— Ronnie
fonte
1

Lo stesso problema per me, ma la fonte dei miei problemi era il vecchio formato della password. Mentre mysql può essere forzato a connettersi usando il vecchio formato con "skip-secure-auth", mysql_upgrade non ha questa opzione. Devi prima aggiornare la password di root con il nuovo formato e quindi puoi aggiornare il tuo mysql.

— Leandro Dardini
fonte
1

Ho avuto lo stesso problema con l'aggiornamento da 5.1 a 5.5.

Questo ha funzionato per me: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Il mio errore è stato probabilmente causato dalle autorizzazioni per il percorso del socket, ma non ho il tempo di verificarne la causa.

— Capt
fonte
Avevo spostato il mio DataDir a un certo punto, immagino che sia per questo che avevo bisogno del percorso del socket
— zzapper
0

Mi sono appena imbattuto anche in questo dopo aver aggiornato il mio sistema da Mint 12 a Mint 15. Avevo archiviato / var / lib / mysql e l'ho rimesso a posto dopo l'aggiornamento. Ho eseguito il primo mysqlcheckdal commento di user16081 e si è lamentato di mysql.sock.

Ho iniziato a usare mysqld /usr/sbin/mysqld &e ho mysql_upgradefunzionato bene.

— Marty Vance
fonte
È un metodo abbastanza spaventoso per aggiornare MySQL, ma sono contento che abbia funzionato per te.
— Aaron Copley,
@ aaron-copley: in realtà non ha funzionato completamente. MySQL 5.5.32 ignora parzialmente molte delle mie tabelle InnoDB; compaiono in SHOW TABLES, ma per il resto non esistono. Attualmente sto cercando di far funzionare mysql-utilities, ma questo si lamenta della mancanza di moduli Python.
— Marty Vance,
0

Ho riscontrato lo stesso problema.
Ho risolto includendo il -S /path/to/mysql.sock

Nel mio caso particolare l'output di mysql_upgrade è stato:
Alla ricerca di 'mysql' come: mysql
Alla ricerca di 'mysqlcheck' come: mysqlcheck
ERRORE FATALE: aggiornamento fallito

È piuttosto inutile. --verbose non ha fatto differenza.

Collegandomi ho optato per il seguente comando e ha funzionato come un incantesimo:
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Spero che sia d'aiuto.

— bfieber
fonte
0

Ho affrontato questo problema e ho scoperto che

  1. richiedeva che il servizio MySQL fosse in esecuzione

  2. richiedeva username e password

— Sruit A.Suk
fonte
0

Ho riscontrato lo stesso problema.

Ho risolto questo problema installando un nuovo database mysql_install_db --user=mysqlcome descritto nei commenti del mio rc.mysqlfile in / etc.

Quindi sono stato in grado di avviare il demone mysql e usare 'mysql' o qualunque cosa tu voglia connessa con il pacchetto mysql.

Ho avuto questo problema sul braccio slackware, ma supponiamo che in questo caso non abbia importanza.

— user323106
fonte
0

Nel mio caso ho avuto alcune versioni di mysqld in esecuzione localmente che hanno fatto fallire mysql_upgrade con Errore: fallito durante il recupero della versione del server! Potrebbe essere dovuto ad accesso non autorizzato. ps aux | grep mysqle assicurati che mysqld sia tutto spento. Quindi, disinstalla tutta la versione, reinstalla la versione corretta. E dopo che mysql_upgrade ha iniziato a funzionare.

— Laurens Bronwasser
fonte
-1

provare 

mysql_upgrade --verbose

o forse anche (o entrambi)

--debug-check --debug-info
— Alexus
fonte
Ho provato quelle, nessuna vera informazione utile, non credo |;
— Jim Rubenstein,
riavviato e incollato alcune informazioni del registro errori \; non so perché continuerebbe a ripetere ripetutamente gli stessi errori.
— Jim Rubenstein,
sembra che tu abbia un errore lì - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existpenso che sia ciò che causa il fallimento dell'intera cosa.
— alexus
ma prima, prova mysql_upgrade --version e fornisci un output per quello.
— alexus
mysql_upgrade --versionnon produce alcun output di versione (solo l'errore FATAL ERROR). mysql --versionis mysql Ver 14.14 Distrib 5.5.32, per debian-linux-gnu (x86_64) usando readline 6.2, e la versione mysqld è 5.5
— Jim Rubenstein,
-3

L'utente root per MySQL è chiamato "admin", non root. Il comando giusto è

mysql_upgrade -uadmin -p
— Marco Marsala
fonte
Questo è assolutamente sbagliato. L'utente root in MySQL è root.
— dr01,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.