Não é possível iniciar o mysql - mysql respawning muito rápido, parou

Question

Hoje eu fiz uma nova instalação do Ubuntu 12.04 e fui configurar meu ambiente de desenvolvimento local. Eu instalei o mysql e editei /etc/mysql/my.cnf para otimizar o InnoDB, mas quando eu tento reiniciar o mysql, ele falha com um erro:

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

O syslog revela que há um problema com o script de inicialização:

> 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

Alguma idéia?

Coisas que já experimentei:

Eu pesquisei e encontrei um bug do Ubuntu com o apparmor ( link ), Eu mudei o apparmor do modo enforce para o modo de reclamar:

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

mas isso não ajudou. Ainda não consigo iniciar o mysql.

Eu também achei que o problema poderia ser porque os arquivos de log do InnoDB eram de tamanho diferente do que o mysql estava esperando. Eu removi os arquivos de log innodb antes de reiniciar usando: sudo mv /var/lib/mysql/ib_logfile* /tmp . Não tem sorte.

Solução alternativa: Eu re-instalei o 12.04, certifiquei-me de não tocar em /etc/mysql/my.cnf de forma alguma. O Mysql está funcionando para que eu possa continuar com o que preciso fazer. Mas vou precisar editá-lo em algum momento - Espero ter descoberto uma solução, ou essa pergunta já terá sido respondida ...

    

Answer 1

Eu finalmente descobri o problema. Basicamente, a definição de alguns parâmetros foi removida da versão anterior do mysql e foi substituída por nomes diferentes. Para corrigir, em /etc/mysql/my.cnf, substitua:

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

com:

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

Este é o relatório de bug associado à barra de lançamento: link .

Ou execute facilmente:

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

Mas certifique-se de que não há instalação antiga da versão do mysql instalada, se houver, por favor, remova:

# Miraz quick mysql package check
dpkg -l *mysql*

    

Answer 2

Innodb tem uma configuração padrão (innodb_buffer_pool_size) que é configurada para 128M - isso pode ser muito grande para o seu servidor (especialmente se você estiver usando uma pequena Amazon EC2 AMI - que eu era). A correção que funcionou para mim foi adicione a seguinte linha a /etc/mysql/my.cnf

innodb_buffer_pool_size = 16M

Eu escrevi sobre essa correção aqui link

    

Answer 3

Eu tive um problema semelhante. Foi frustrante porque não consegui ver nenhum log de erro indicando qual era o problema.

No meu caso, o valor que eu tinha definido para innodb_buffer_pool_size era muito grande para a memória do servidor.

Eu descobri isso executando o mysqld diretamente como o usuário mysql.

# su mysql
# mysqld

Dessa forma, você realmente vê a saída de erros.

    

Answer 4

Eu também tive um problema semelhante. Os itens abaixo dizem que eles foram removidos do servidor mysql 5.5. Se você os tiver no seu my.cnf , não será iniciado. Comente-os com # .
(Informações derivadas de: link )

As opções afetadas são mostradas nesta lista:

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

    

Answer 5

Parece reduzir-se a erros na configuração do MySQL, localizada em /etc/mysql/my.cnf e arquivos em /etc/mysql/conf.d/ .

No meu caso, foi um valor bind-address errado, porque o endereço IP da minha máquina havia mudado e o MySQL não podia mais se ligar. Fique à vontade para saber mais sobre isso em este artigo do blog .

    

Answer 6

Uma boa maneira de depurar as falhas no processo de pós-inicialização ( /etc/init/mysql.conf ) é verificar os logs de inicialização:

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

Isso me deu um erro de soquete:

% bl0ck_qu0te%

No meu caso, isso foi causado por uma configuração user ausente no grupo [mysqld] em my.cnf

    

Answer 7

Quando tive um erro semelhante no MySQL ("Falha ao iniciar o trabalho") após a atualização de 11,10 para 12,04, comente o # 27 em link funcionou perfeitamente para mim. Citação:

% bl0ck_qu0te%     

Answer 8

Para mim, a solução foi remover a linha ...

set-variable = max_connections=200

... que é a sintaxe do MySQL 3.xe precisa ser alterada para

max_connections=200

    

Answer 9

Eu tive o mesmo problema. Acabou sendo as replicações do escravo mestre my.cnf do mysql. Verifique seu /var/log/mysql/error.log .

Espero que seja uma pequena ajuda. Verifique as configurações do mysql primeiro antes de perder duas horas com o apparmor que funciona bem.

    

Answer 10

Eu tive os mesmos problemas, para mim o bind-address foi definido incorretamente no meu arquivo /etc/mysql/my.cnf . Então parece que qualquer coisa que não está bem no my.cnf pode causar esse problema. Eu não encontrei nada nos logs que indicaram isso como o problema.

    

Answer 11

Meu problema foi 0% de espaço livre! Verifique novamente: -)

    

Answer 12

Verifique as permissões /tmp . Eu tive esse problema, depois de muito tempo pesquisando e reiniciando, descobri que /tmp permissões era 755.

Eu mudei para 777 e mysql começou bem.

    

Answer 13

Após uma atualização automática para o mysqld-5.5.53 ubuntu 14.04.1, o mysql não seria iniciado. Estas linhas apareceram no meu syslog:

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

O problema foi resolvido criando este diretório:

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

    

Answer 14

Atualizei a versão do MySQL e do AppArmor conforme sugerido aqui para corrigir esse problema no Ubuntu 12.04 rodando na instância do Amazon ec2. Eu ainda recebo o erro algumas vezes, mas o MySQL se reinicia automaticamente.

    

Answer 15

Eu tive as mesmas mensagens de erro, mas a causa foi diferente. Minhas tabelas InnoDB estavam corrompidas, porque todo o sistema de arquivos entrava no modo somente leitura. Corrigi a corrupção adicionando a seguinte linha ao /etc/mysql/my.cf

innodb_force_recovery = 1

Eu iniciei o MySQL:

sudo service mysql start

O MySQL foi iniciado e eu descartei / exportei todas as tabelas. Eu mudei o innodb_force_recovery para 0 (= padrão) e reiniciei o MySQL:

sudo service mysql restart

Estou usando o Ubuntu 12.04 com o MySQL 5.5. Demorou muito tempo até encontrar o problema e espero poder ajudar alguém com esta resposta. Veja também link

    

Answer 16

No meu caso, o problema era a permissão do arquivo /etc/mysql/my.cnf .

Eu mudei para censidade, mas isso causou erros como

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"

A permissão my.cnf foi 766 e eu mudei para 744 e dois dos três erros foram embora. Ainda há uma mensagem de erro semelhante, mas não impediu o início do mysql.

Espero que isso ajude ...

    

Answer 17

No meu caso, tive uma declaração errada de bind-address . Corri ifconfig para descobrir o endereço IP privado do EC2 e atualizei-o no arquivo /etc/mysql/my.cnf .

    

Answer 18

No meu caso, encontrei um problema de permissão em / tmp. Eu apenas configurei a permissão de diretório do tmp para 766 e reinicie o serviço mysql. Corrigido.