Ponieważ żadna z powyższych odpowiedzi tak naprawdę nie wyjaśnia tego, co się stało, postanowiłem wtrącić się i przedstawić kilka szczegółów tego problemu.
Tak, rozwiązaniem jest uruchomienie polecenia MySQL Upgrade w następujący sposób: mysql_upgrade -u root -p --force
ale co się stało?
Podstawową przyczyną tego problemu jest uszkodzenie performance_schema
, które może być spowodowane przez:
- Korupcja organiczna (ilość woluminów w kaboomie, błąd silnika, problem ze sterownikiem jądra itp.)
- Korupcja podczas łatki mysql (często zdarza się, że dzieje się to podczas łatki mysql, szczególnie w przypadku głównych aktualizacji wersji)
- Prosty „upuść bazę danych Performance_schema” oczywiście spowoduje ten problem i będzie miał takie same objawy, jak gdyby był uszkodzony
Ten problem mógł występować w Twojej bazie danych nawet przed łatką, ale to, co wydarzyło się w MySQL 5.7.8, polega na tym, że flaga show_compatibility_56
zmieniła domyślną wartość z ON
domyślnej zmiany na OFF
. Ta flaga kontroluje zachowanie silnika w zapytaniach dotyczących ustawiania i odczytu zmiennych (sesyjnych i globalnych) w różnych wersjach MySQL.
Ponieważ MySQL 5.7+ zaczął odczytywać i przechowywać te zmienne performance_schema
zamiast na information_schema
, ta flaga została wprowadzona tak, jak ON
w pierwszych wydaniach, aby zmniejszyć promień wybuchu tej zmiany i poinformować użytkowników o zmianie i przyzwyczaić się do niej.
OK, ale dlaczego połączenie się nie udaje? Ponieważ w zależności od używanego sterownika (i jego konfiguracji) może on uruchamiać polecenia dla każdego nowego połączenia inicjowanego z bazą danych ( show variables
na przykład). Ponieważ jedno z tych poleceń może próbować uzyskać dostęp do uszkodzonego performance_schema
, całe połączenie zostaje przerwane, zanim zostanie w pełni zainicjowane.
Podsumowując, być może (teraz nie można stwierdzić) performance_schema
brakowało lub było uszkodzone przed łataniem. Łatka do 5.7.8 następnie zmusiła silnik do odczytania zmiennych performance_schema
(zamiast, z information_schema
którego odczytuje je z powodu zmiany flagi ON
). Ponieważ performance_schema
został uszkodzony, połączenia nie działają.
Uruchamianie aktualizacji MySQL jest najlepszym rozwiązaniem, pomimo przestoju. Włączenie flagi jest jedną z opcji, ale ma ona swój własny zestaw implikacji, jak już wskazano w tym wątku.
Oba powinny działać, ale rozważ konsekwencje i poznaj swoje wybory :)
5.7.8-rc
wersji i przywrócenie z pełnej kopii zapasowej DB.