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

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:

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)

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.

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`

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

Ten sam problem! Rozwiązanie dla mnie pochodzi z http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

W skrócie: błąd wprowadza w błąd! uruchom mysql_upgrade -u root -pz DB on-line i podaj hasło roota.

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ć.

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

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.

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.

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.

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.

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.

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

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.

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ć.

próbować

mysql_upgrade --verbose 

a może nawet (lub oba)

--debug-check --debug-info

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

mysql_upgrade -uadmin -p