Nie można uruchomić mysql - mysql odradza się zbyt szybko, zatrzymany

33

Dzisiaj zrobiłem nową instalację Ubuntu 12.04 i zacząłem konfigurować lokalne środowisko programistyczne. Zainstalowałem mysql i edytowałem, /etc/mysql/my.cnfaby zoptymalizować InnoDB, ale kiedy próbuję ponownie uruchomić mysql, błąd kończy się niepowodzeniem:

[20:53][tom@Pochama:/var/www/website] (master) $ sudo service mysql restart
start: Job failed to start

Syslog ujawnia problem ze skryptem init:

> tail -f /var/log/syslog

Apr 28 21:17:46 Pochama kernel: [11840.884524] type=1400 audit(1335644266.033:184): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=760 comm="apparmor_parser"
Apr 28 21:17:47 Pochama kernel: [11842.603773] init: mysql main process (764) terminated with status 7
Apr 28 21:17:47 Pochama kernel: [11842.603841] init: mysql main process ended, respawning
Apr 28 21:17:48 Pochama kernel: [11842.932462] init: mysql post-start process (765) terminated with status 1
Apr 28 21:17:48 Pochama kernel: [11842.950393] type=1400 audit(1335644268.101:185): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=811 comm="apparmor_parser"
Apr 28 21:17:49 Pochama kernel: [11844.656598] init: mysql main process (815) terminated with status 7
Apr 28 21:17:49 Pochama kernel: [11844.656665] init: mysql main process ended, respawning
Apr 28 21:17:50 Pochama kernel: [11845.004435] init: mysql post-start process (816) terminated with status 1
Apr 28 21:17:50 Pochama kernel: [11845.021777] type=1400 audit(1335644270.173:186): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=865 comm="apparmor_parser"
Apr 28 21:17:51 Pochama kernel: [11846.721982] init: mysql main process (871) terminated with status 7
Apr 28 21:17:51 Pochama kernel: [11846.722001] init: mysql respawning too fast, stopped

Jakieś pomysły?


Rzeczy, które próbowałem już:

Poszukałem go i znalazłem błąd Ubuntu z apparmor ( https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/970366 ), zmieniłem program z trybu wymuszania na tryb narzekania:

sudo apt-get install apparmor-utils
sudo aa-complain /usr/sbin/mysqld
sudo /etc/init.d/apparmor reload

ale to nie pomogło. Nadal nie mogę uruchomić MySQL.

Pomyślałem również, że problem może wynikać z tego, że pliki dziennika InnoDB miały inny rozmiar niż się spodziewał mysql. Usunąłem InnoDB plików dziennika przed ponownym użyciem: sudo mv /var/lib/mysql/ib_logfile* /tmp. Ale bez powodzenia.

Obejście: Ponownie zainstalowałem 12.04, upewniłem się, że nie dotykam /etc/mysql/my.cnfw żaden sposób. MySQL działa, więc mogę zacząć od tego, co muszę zrobić. Ale w pewnym momencie będę musiał go edytować - mam nadzieję, że wymyślę rozwiązanie lub w tym momencie odpowiedź na to pytanie ...

Tomek
źródło

Odpowiedzi:

29

W końcu zrozumiałem problem. Zasadniczo definicja niektórych parametrów została usunięta z poprzedniej wersji mysql i została zastąpiona inną nazwą. Aby to naprawić, w pliku /etc/mysql/my.cnf zamień:

# Tom Added to ensure the server character set is set to utf8
default-character-set = utf8
default-collation     = utf8_general_ci

z:

# Tom Added to ensure the server character set is set to utf8
character_set_server  = utf8
collation_server      = utf8_general_ci

To jest powiązany raport o błędzie startera: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/958120 .

Lub łatwo uruchomić:

# Miraz added dpkg-reconfigure
dpkg-reconfigure mysql-server-5.5

Ale upewnij się, że nie ma zainstalowanej starej wersji mysql, jeśli tak, usuń:

# Miraz quick mysql package check
dpkg -l *mysql*
Tomek
źródło
Nie miałem tego problemu, ale dpkg-reconfigure mysql-server-5.5naprawiłem cokolwiek było nie tak w mojej konfiguracji.
David Purdue
w moim przypadku problemem okazała się niepoprawna nazwa właściwości w /etc/mysql/my.cnf. Z tego bloga: dangtrinh.com/2014/05/… , uruchom mysqld -v. Próbowałem googling mysql kod wyjścia 7, bez powodzenia. Domyślam się, że kod wyjścia 7 ma związek z błędami w analizie pliku konfiguracyjnego mysql.
MaasSql
Miałem ten sam problem, ale trudno mi było wyśledzić, ponieważ moja wadliwa konfiguracja znajdowała się w katalogu /etc/mysql/conf.d/*, a także dlatego, że istniały stare dzienniki o nazwie /var/log/mysql.*, które spowodowały, że nie zauważyłem active logs / var / log / mysql / *.
Dave Burt
1
uwaga: utf8_unicode_cijest lepszy. Teraz nawetutf8mb4_unicode_ci
Akshay
10

Innodb ma ustawienie domyślne (innodb_buffer_pool_size), które jest ustawione na 128M - to może być zbyt duże dla twojego serwera (szczególnie jeśli używasz małego Amazon EC2 AMI - który byłam) Poprawką, która działała dla mnie było dodanie następującego linia do /etc/mysql/my.cnf

innodb_buffer_pool_size = 16M

Napisałem o tej poprawce tutaj http://www.mlynn.org/2012/07/mysql-5-5-on-ubuntu-12-04-job-failed-to-start

Michael Lynn
źródło
Okazało się, że w mojej maszynie wirtualnej zabrakło pamięci. Ustawienie innodb_buffer_pool_sizeniższej wartości było jedną z części rozwiązania, ale uwaga: może zabraknąć pamięci.
thaddeusmt
10

Miałem podobny problem. To było frustrujące, ponieważ nie widziałem żadnych dzienników błędów wskazujących na problem.

W moim przypadku wartość ustawiona dla innodb_buffer_pool_size była zbyt duża dla pamięci serwera.

Znalazłem to, uruchamiając mysqld bezpośrednio jako użytkownik mysql.

# su mysql
# mysqld

W ten sposób faktycznie widzisz wyjście błędu.

Joel
źródło
2
To świetna wskazówka, starałem się wyciągnąć z mysql jakieś sensowne informacje debugowania. Dzięki!
eageranalyst
3

Miałem również podobny problem. Poniższe elementy mówią, że zostały usunięte z serwera mysql 5.5.
Jeśli masz je w swoim my.cnf, to się nie uruchomi. Skomentuj je za pomocą #.
(Informacje pochodzą z: http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html )

Opcje, których dotyczy problem, pokazano na tej liście:

 --master-host
 --master-user
 --master-password
 --master-port
 --master-connect-retry
 --master-ssl
 --master-ssl-ca
 --master-ssl-capath
 --master-ssl-cert
 --master-ssl-cipher
 --master-ssl-key
Michael Salamon
źródło
Doskonały! Dokładnie to, co mnie zrzuciło. Dzięki.
Jim W.
3

Wydaje się sprowadzać do błędów w konfiguracji MySQL, zlokalizowanej w /etc/mysql/my.cnfplikach i w /etc/mysql/conf.d/.

W moim przypadku była to niepoprawna bind-addresswartość, ponieważ zmienił się adres IP mojego komputera i MySQL nie mógł się już powiązać. Więcej informacji na ten temat można znaleźć w tym artykule na blogu .

boteeka
źródło
2

Dobrym sposobem na debugowanie błędów w procesie po uruchomieniu ( /etc/init/mysql.conf) jest sprawdzenie dzienników aktualizacji:

sudo tail -f /var/log/upstart/mysql.log 

To dało mi błąd gniazda:

błąd: „Nie można połączyć się z lokalnym serwerem MySQL przez gniazdo

W moim przypadku było to spowodowane brakującym userustawieniem w [mysqld]grupie wmy.cnf

prusswan
źródło
1

Kiedy miałem podobny błąd MySQL („Uruchomienie zadania nie powiodło się”) po aktualizacji z 11.10 do 12.04, komentarz nr 27 na https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/ 573318? Komentarze = wszystko działało idealnie dla mnie. Zacytować:

Problemem było dla mnie to, że plik /etc/apparmor.d/local/usr.sbin.mysqld nie istniał po aktualizacji. Ręcznie skopiowałem jeden z jednego z pustych (tzn. Miałem tylko komentarz w nagłówku), a potem wszystko było gotowe.

marcvangend
źródło
1

Dla mnie rozwiązaniem było usunięcie linii ...

set-variable = max_connections=200

... która jest składnią MySQL 3.x i należy ją zmienić na

max_connections=200
Ken West
źródło
1

Miałem ten sam problem. Okazało się, że są to repliki master slave mysql my.cnf. Sprawdź swój/var/log/mysql/error.log .

Mam nadzieję, że to mała pomoc. Najpierw sprawdź ustawienia mysql, zanim stracisz dwie godziny z apparmor, który działa dobrze.

shadowdroid
źródło
1

Miałem te same problemy, dla mnie bind-addresszostały niepoprawnie ustawione w moim /etc/mysql/my.cnfpliku. Wygląda więc na to, że wszystko, co nie jest właściwe w pliku my.cnf, może powodować ten problem. W dziennikach nie znalazłem niczego, co wskazywałoby na ten problem.

Chris
źródło
1

Moim problemem było 0% wolnego miejsca! Podwójne sprawdzenie :-)

moamahi
źródło
1

Sprawdź /tmpuprawnienia. Miałem ten problem, po wielu latach googleowania i ponownym uruchomieniu, dowiedziałem się o tym/tmp uprawnienia to 755.

Zmieniam go na 777 i mysqlzaczynam dobrze.

shgnInc
źródło
ta rzecz w starożytności, ale to był mój problem ... nie wiem jak to się zmieniło ...
TheHidden
w niektórych przypadkach przez zmianę systemu plików lub zamontowanie /tmpna nowej partycji.
shgnInc,
1

Po automatycznej aktualizacji do mysqld-5.5.53 ubuntu 14.04.1 mysql nie uruchomi się. Te wiersze pojawiły się w moim dzienniku systemowym:

Oct 27 06:05:51 hostname kernel: [  593.168925] init: mysql post-start process (4997) terminated with status 1
Oct 27 06:05:51 hostname kernel: [  593.178241] type=1400 audit(1477562751.231:31): apparmor="STATUS" operation="profile_replace" profile="unconfined" name
Oct 27 06:05:51 hostname kernel: [  593.204392] init: mysql main process (5032) terminated with status 1
Oct 27 06:05:51 hostname kernel: [  593.204404] init: mysql respawning too fast, stopped

Problem został rozwiązany przez utworzenie tego katalogu:

sudo mkdir /var/lib/mysql-files
sudo chmod 700 /var/lib/mysql-files
sudo chown mysql:mysql /var/lib/mysql-files
sudo /etc/init.d/mysql start
Yapsr
źródło
0

Właśnie zaktualizowałem MySQL i wersję AppArmor, jak sugerowano tutaj, aby rozwiązać ten problem na Ubuntu 12.04 działającym na instancji Amazon ec2. Nadal pojawia się błąd kilka razy, ale MySQL uruchamia się ponownie automatycznie.

Jay Prakash
źródło
1
Witamy w Ask Ubuntu! Chociaż teoretycznie może to odpowiedzieć na pytanie, lepiej byłoby zawrzeć tutaj istotne części odpowiedzi i podać odnośnik.
Ringtail
0

Miałem te same komunikaty o błędach, ale przyczyna była inna. Moje tabele InnoDB były uszkodzone, ponieważ cały system plików przeszedł w tryb tylko do odczytu. Naprawiłem uszkodzenie, dodając następujący wiersz do /etc/mysql/my.cf

innodb_force_recovery = 1

Uruchomiłem MySQL:

sudo service mysql start

MySQL zaczął się i zrzuciłem / wyeksportowałem wszystkie tabele. Zmieniłem innodb_force_recovery na 0 (= domyślnie) i zrestartowałem MySQL:

sudo service mysql restart

Używam Ubuntu 12.04 z MySQL 5.5. Minęło dużo czasu, zanim znalazłem problem i mam nadzieję, że mogę pomóc komuś z tą odpowiedzią. Zobacz także http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

Coanda
źródło
0

W moim przypadku problemem było /etc/mysql/my.cnfpozwolenie na plik.

Zmieniłem to dla wygody, ale spowodowało to takie błędy

kernel: [604528.290448] type=1400 audit(1424350956.727:193): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=15008 comm="apparmor_parser"

my.cnfPozwolenie było 766 i zmieniłem go na 744, a dwa z trzech błędów odszedł. Nadal występuje jeden podobny komunikat o błędzie, ale nie uniemożliwił on uruchomienia mysql.

Mam nadzieję że to pomoże...

Marcelo_nnn
źródło
0

W moim przypadku miałem złe bind-addressoświadczenie. Pobiegłem znaleźć ifconfigprywatny adres IP EC2 i zaktualizowałem go w /etc/mysql/my.cnfpliku.

Ralph
źródło
0

W moim przypadku znalazłem problem z uprawnieniami na / tmp. Właśnie ustawiłem uprawnienia katalogu tmp na 766 i zrestartowałem usługę mysql. Naprawiono.

Fernando Luis Barbosa
źródło