`mysql_upgrade` kończy się niepowodzeniem bez podania prawdziwego powodu

70

Aktualizuję z MySQL 5.1 do 5.5, uruchamiam mysql_upgradei otrzymuję ten wynik:

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

Jakieś pomysły na to, gdzie szukać tego, co się dzieje (a co się nie dzieje?), Abym mógł naprawić to, co jest złe, i faktycznie uruchomić mysql_upgrade?

Dzięki!

Więcej wyników:

# 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

Po wyłączeniu mysqld --skip-grant-tablesurządzeń mysqladmin shutdowni ponowne mysql poprzez service mysql startdziennik błędów pętle przez ten zbiór błędów w kółko:

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

Dziennik MySQL podczas uruchamiania przez 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)

Jak rozumiem, wszystkie problemy dotyczące struktury / istnienia tabeli (w odniesieniu do tabel systemowych mysql) powinny zostać naprawione poprzez uruchomienie mysql_upgrade:

Jim Rubenstein
źródło
Prawdopodobnie nic też nie mysqldjest warte, działa z --skip-grant-tablesopcją. Mogę połączyć się za pośrednictwem mysqlterminala bez poświadczeń i nie otrzymuję żadnych błędów za pośrednictwem syslog ani nigdzie indziej, kiedy mogę uruchomićmysql_upgrade
Jim Rubenstein
MySQL Reference Manual obejmuje modernizację do 5,5 z 5,1 całkiem dobrze. Jeśli zastosowałeś się do wszystkich instrukcji tutaj, warto o tym wspomnieć. Jeśli nie, cóż ...
Aaron Copley
Jeśli użytkownik root mysql nie ma hasła, nie dołączaj `-p` w` mysql_upgrade -u root -p`
Jeferex

Odpowiedzi:

95

Myślę, że potrzebuje nazwy użytkownika i hasła

mysql_upgrade -u root -p

Jeśli ich nie zdam, dostaję błąd

Edycja : dzięki komentarzom wiem, że istnieją inne powody, może rzadziej, ale najlepiej też o nich pamiętać

Więc pojawia się ten błąd, kiedy

  • nie przekazałeś nazwy użytkownika i hasła
  • zdałeś swoje poświadczenia, ale się myliły
  • serwer MySQL nie działa
  • tabele uprawnień są zrujnowane (wtedy musisz zrestartować MySQL za pomocą mysqld --skip-grant-table)
  • brakuje tabeli mysql.plugin (zobaczysz błąd podczas uruchamiania MySQL, który sugeruje uruchomienie ... mysql_upgrade, i to się nie powiedzie. Prawdopodobnie masz trochę przestarzałej konfiguracji w my.cnf)
Riccardo Galli
źródło
23
To był dokładnie problem, który miałem - dlaczego, u diabła, nie mógł po prostu powiedzieć „Nie można uwierzytelnić”, „Błąd połączenia” czy coś takiego? Tak zły ...
les2
3
Chłopaki, ten sam błąd pojawia się, jeśli hasło też jest nieprawidłowe. więc bądź informowany.
Yoosaf Abdulla,
3
Ten sam błąd pojawia się, jeśli serwer nie działa, nawet jeśli wydaje się, że akceptuje hasło.
Raman
1
gdy tabela bazy danych lub format bazy danych również jest uszkodzony, to też nie działa, musisz uruchomić demona za pomocą „mysqld --skip-grant-tables” i uruchomić mysql_upgrade w innym terminalu!
Henning
+1 za to. Kolejny powód, dla którego nienawidzę MySQL
Excalibur,
9

Właśnie spotkałem się z tymi precyzyjnymi objawami podczas aktualizacji z 5.5 do 5.6, i okazało się, że jest to problem z osiągalnością usługi.

Mimo że klient MySQL cli mógł się połączyć z moją lokalną instancją DB, podając tylko -u i -p, musiałem również podać -h 127.0.0.1 dla mysql_upgrade, ponieważ próbowała połączyć się z plikiem gniazda i nie powiodła się próba.

Aubrey Falconer
źródło
to był dokładnie mój problem, ponieważ uruchamiam mysqd w następujący sposób: mysqld --skip-grant-tables --user = mysql
Rodo
9

To wydaje się być serwerem Plesk, podczas korzystania z Plesk nie ma roota dla Mysql, ale administrator Mysql o nazwie admin, więc to polecenie powinno działać na Plesk tak, jak próbowałem wcześniej:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
linuxman1
źródło
Działa to
5

możesz spróbować uruchomić je kolejno, aby zobaczyć, gdzie się nie powiedzie:

mysql_upgrade wykonuje następujące polecenia, aby sprawdzić i naprawić tabele oraz zaktualizować tabele systemowe:

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

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

user16081-JoeT
źródło
1
Myślałem o tym, ale fix_priv_tablesjest to skrypt, który jest generowany mysql_upgradew celu naprawy tabel przywilejów
Jim Rubenstein
dobra uwaga, może wypróbujesz tylko pierwszą linię mysqlcheck? I spróbuj uruchomić bezpośrednio z folderu bin, fwiw,/usr/bin/mysql_upgrade
user16081-JoeT
3

To pytanie jest niezwykle ogólne i przepraszam za to.

Nie mogłem znaleźć bezpośredniej przyczyny i rozwiązania problemu, który miałem, więc postanowiłem ponownie zainstalować MySQL, aby sprawdzić, czy to zadziała. Okazuje się, że ponowna instalacja załatwiła sprawę. To był kiepski sposób, aby to naprawić, ale była to jedyna opcja, którą mi pozostało.

Wiele innych odpowiedzi na to pytanie to problemy, które musiałem rozwiązać, aby początkowo uruchomić mysql_upgrade, ale z jakiegokolwiek powodu - nie udało się, ponieważ próbowałem uruchomić automatyczne zapytania i nie mogłem znaleźć dokumentacji, na której zapytania, które uruchomił, więc mogłem je naprawić.

Jim Rubenstein
źródło
Tak, kiedy katalog danych mysql zostanie uszkodzony, praktycznie nic nie możesz zrobić
Krauser
2

Musisz sprawdzić uprawnienia do wszystkich plików w danych mysql. Powinien to być ten sam właściciel mysql PID (mysql lub _mysql). Zdarza się to czasami, ponieważ przywracanie danych z pliku bez odpowiedniego pozwolenia. Na przykład, jeśli dane mysql znajdują się w katalogu / var / lib / mysql

chown -R mysql /var/lib/mysql
asofyan
źródło
2

Nasz DBA odinstalował mysql w wersji 5.0.95 zamiast aktualizacji do wersji 5.5.39. Dezinstalacyjne wsparte w górę /etc/my.cnf, aby /etc/my.cnf.rpmsavenastępnie usuwa się, a to zapobiega MySQL z uruchomieniem odpowiednio:

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

Możesz wykonać dowolną z następujących czynności:

  • Porównaj pliki my.cnf ręcznie i przenieś odpowiednie ustawienia konfiguracji dla InnoDB

  • Przywróć my.cnf.rpmsavekopię oryginalną (najpierw sprawdź nowe ustawienia domyślne, które powinieneś dodać!)

  • Użyj narzędzia vimdiffporównywania, takiego jak porównanie z my.cnf.rpmsavenowym my.cnfi przywróconym do poprawek wprowadzonych do konfiguracji MySQL, w tym ustawień InnoDB.

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

Zrobiłem ostatnią opcję, a następnie mogłem uruchomić MySQL:

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

a teraz mysql_upgradedziała dobrze, mysql_upgrade -uroot -pwięc poprosił mnie o hasło roota.

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

Mam nadzieję że to pomoże!

a także używanie mysql_upgrade -uroot -pnie powiodło się, ponieważ wymaga działania MySQL!

Zdobyta wiedza:

  • Wykonaj kopię zapasową my.cnf przed aktualizacją ... I faktycznie wykonaj aktualizację w miejscu zamiast odinstalować, a następnie zainstalować nowszą wersję.
  • Uruchom MySQL, abyś mógł użyć mysql_upgrade.
  • Zysk.
Ronnie
źródło
1

Ten sam problem dla mnie, ale źródłem moich problemów był stary format hasła. Chociaż mysql może zostać zmuszony do połączenia przy użyciu starego formatu z opcją „skip-secure-auth”, mysql_upgrade nie ma tej opcji. Najpierw musisz zaktualizować hasło roota do nowego formatu, a następnie zaktualizować mysql.

Leandro Dardini
źródło
1

Miał ten sam problem przy aktualizacji z 5.1 do 5.5.

To działało dla mnie: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Mój błąd został prawdopodobnie spowodowany przez uprawnienia do ścieżki gniazda, ale nie mam czasu, aby sprawdzić, czy to była przyczyna.

Capt
źródło
Kiedyś przeniosłem swój DataDir, chyba dlatego potrzebowałem ścieżki do gniazda
zzapper
0

Właśnie na to wpadłem po aktualizacji mojego systemu z wersji Mint 12 do wersji Mint 15. Zarchiwizowałem / var / lib / mysql i przywróciłem go po aktualizacji. Uruchomiłem pierwszy mysqlcheckz komentarza user16081 i narzekał on na mysql.sock.

Zacząłem używać mysqld /usr/sbin/mysqld &i mysql_upgradedziałałem dobrze.

Marty Vance
źródło
To dość przerażająca metoda aktualizacji MySQL, ale cieszę się, że zadziałała dla ciebie.
Aaron Copley,
@ aaron-copley: właściwie to nie działało całkowicie. MySQL 5.5.32 częściowo ignoruje wiele moich tabel InnoDB; pojawiają się w SHOW TABLES, ale poza tym nie istnieją. Obecnie próbuję uruchomić narzędzia mysql, ale to narzeka na brakujące moduły python.
Marty Vance,
0

Natknąłem się na ten sam problem.
Rozwiązałem to, dołączając -S /path/to/mysql.sock

W moim szczególnym przypadku dane wyjściowe komendy mysql_upgrade brzmiały:
Szukanie „mysql” jako: mysql
Szukanie „mysqlcheck” jako: mysqlcheck
BŁĄD FATALNY : Aktualizacja nie powiodła się

To całkiem bezużyteczne. - verbose nie zrobił różnicy.

Podłączając się, zdecydowałem się na następującą komendę i działało to jak urok:
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Mam nadzieję, że to pomoże.

bfieber
źródło
0

Napotkałem ten problem i dowiedziałem się, że

  1. wymagało uruchomienia usługi MySQL

  2. wymagało nazwy użytkownika i hasła

Sruit A.Suk
źródło
0

Napotkałem ten sam problem.

Rozwiązałem to, instalując nową bazę danych mysql_install_db --user=mysqlzgodnie z opisem w komentarzach mojego rc.mysqlpliku w / etc.

Potem byłem w stanie uruchomić demona mysql i użyć „mysql” lub cokolwiek chcesz połączyć z pakietem mysql.

Miałem ten problem z ramieniem Slackware, ale załóżmy, że nie ma to znaczenia w tym przypadku.

użytkownik323106
źródło
0

W moim przypadku miałem kilka wersji mysqld działających lokalnie, które spowodowały błąd mysql_upgrade z błędem: Błąd podczas pobierania wersji serwera! Może to być spowodowane nieautoryzowanym dostępem. ps aux | grep mysqli upewnij się, że mysqld jest zamknięty. Następnie zaparuj odinstaluj wszystkie wersje, zainstaluj ponownie odpowiednią wersję. A potem mysql_upgrade zaczął działać.

Laurens Bronwasser
źródło
-1

próbować

mysql_upgrade --verbose 

a może nawet (lub oba)

--debug-check --debug-info
Alexus
źródło
Próbowałem tych, żadnych naprawdę przydatnych informacji, nie sądzę |
Jim Rubenstein
zrestartowałem i wkleiłem niektóre informacje z dziennika błędów \; nie jestem pewien, dlaczego ciągle powtarzałby te same błędy.
Jim Rubenstein
wygląda na to, że masz tam błąd - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existmyślę, że to właśnie spowodowało awarię.
Alexus
ale wcześniej wypróbuj mysql_upgrade --version i podaj dane wyjściowe.
Alexus
mysql_upgrade --versionnie produkuje danych wyjściowych wersji (tylko błąd BŁĄD FATALNY). mysql --versionjest mysql Ver 14,14 rozdzielczy 5.5.32, na debiana Linux-gnu (x86_64) stosując readline 6,2 i wersji mysqld 5,5
Jim Rubinstein
-3

Użytkownik root dla MySQL nazywa się „admin”, a nie root. Prawidłowe polecenie to

mysql_upgrade -uadmin -p
Marco Marsala
źródło
To absolutnie źle. Użytkownik root w MySQL to root.
dr01