Aktualizuję z MySQL 5.1 do 5.5, uruchamiam mysql_upgrade
i 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-tables
urządzeń mysqladmin shutdown
i ponowne mysql poprzez service mysql start
dziennik 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
:
mysqld
jest warte, działa z--skip-grant-tables
opcją. Mogę połączyć się za pośrednictwemmysql
terminala bez poświadczeń i nie otrzymuję żadnych błędów za pośrednictwem syslog ani nigdzie indziej, kiedy mogę uruchomićmysql_upgrade
Odpowiedzi:
Myślę, że potrzebuje nazwy użytkownika i hasła
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
mysqld --skip-grant-table
)źródło
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.
źródło
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:
źródło
możesz spróbować uruchomić je kolejno, aby zobaczyć, gdzie się nie powiedzie:
z http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html
źródło
fix_priv_tables
jest to skrypt, który jest generowanymysql_upgrade
w celu naprawy tabel przywilejów/usr/bin/mysql_upgrade
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 -p
z DB on-line i podaj hasło roota.źródło
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ć.
źródło
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
źródło
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.rpmsave
następnie usuwa się, a to zapobiega MySQL z uruchomieniem odpowiednio: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.rpmsave
kopię oryginalną (najpierw sprawdź nowe ustawienia domyślne, które powinieneś dodać!)Użyj narzędzia
vimdiff
porównywania, takiego jak porównanie zmy.cnf.rpmsave
nowymmy.cnf
i 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:
a teraz
mysql_upgrade
działa dobrze,mysql_upgrade -uroot -p
więc poprosił mnie o hasło roota.Mam nadzieję że to pomoże!
a także używanie
mysql_upgrade -uroot -p
nie powiodło się, ponieważ wymaga działania MySQL!Zdobyta wiedza:
źródło
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.
źródło
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.
źródło
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
mysqlcheck
z komentarza user16081 i narzekał on na mysql.sock.Zacząłem używać mysqld
/usr/sbin/mysqld &
imysql_upgrade
działałem dobrze.źródło
SHOW TABLES
, ale poza tym nie istnieją. Obecnie próbuję uruchomić narzędzia mysql, ale to narzeka na brakujące moduły python.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.
źródło
Napotkałem ten problem i dowiedziałem się, że
wymagało uruchomienia usługi MySQL
wymagało nazwy użytkownika i hasła
źródło
Napotkałem ten sam problem.
Rozwiązałem to, instalując nową bazę danych
mysql_install_db --user=mysql
zgodnie z opisem w komentarzach mojegorc.mysql
pliku 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.
źródło
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 mysql
i upewnij się, że mysqld jest zamknięty. Następnie zaparuj odinstaluj wszystkie wersje, zainstaluj ponownie odpowiednią wersję. A potem mysql_upgrade zaczął działać.źródło
próbować
a może nawet (lub oba)
źródło
130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
myślę, że to właśnie spowodowało awarię.mysql_upgrade --version
nie produkuje danych wyjściowych wersji (tylko błąd BŁĄD FATALNY).mysql --version
jest mysql Ver 14,14 rozdzielczy 5.5.32, na debiana Linux-gnu (x86_64) stosując readline 6,2 i wersji mysqld 5,5Użytkownik root dla MySQL nazywa się „admin”, a nie root. Prawidłowe polecenie to
źródło
root
.