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


33

Hoje fiz uma nova instalação do ubuntu 12.04 e comecei a configurar meu ambiente de desenvolvimento local. Instalei o mysql e editei /etc/mysql/my.cnfpara otimizar o InnoDB, mas quando 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 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

Alguma ideia?


Coisas que eu já tentei:

Pesquisei no Google e encontrei um bug do Ubuntu com o apparmor ( https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/970366 ), mudei o apparmor do modo de execução para o modo de reclamação:

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

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

Eu também pensei que o problema poderia ser porque os arquivos de log do InnoDB tinham um tamanho diferente do que o mysql esperava. I removido os arquivos de log do InnoDB antes de reiniciar usando: sudo mv /var/lib/mysql/ib_logfile* /tmp. Sem sorte embora.

Solução alternativa: reinstalei o 12.04, certificando-me de não tocar de /etc/mysql/my.cnfforma 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 será respondida nesse ponto ...

Respostas:


29

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 erro associado à barra de ativação: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/958120 .

Ou execute facilmente:

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

Mas verifique se não há nenhuma instalação antiga da versão mysql instalada, se houver, remova:

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

Eu não tive esse problema, mas dpkg-reconfigure mysql-server-5.5corrigi o que estava errado na minha configuração.
— David Purdue

no meu caso, o problema acabou sendo um nome de propriedade digitado incorretamente em /etc/mysql/my.cnf....Deste blog: dangtrinh.com/2014/05/… , execute mysqld -v. Eu tentei pesquisar o código de saída 7 do mysql, sem sucesso. Meu palpite é que o código de saída 7 tem a ver com falhas para analisar o arquivo de configuração do mysql.
— MaasSql 16/03

Eu tive esse mesmo problema, mas achei difícil rastrear porque minha configuração defeituosa estava em /etc/mysql/conf.d/* e também porque havia logs antigos chamados /var/log/mysql.*, o que me levou a não perceber o logs ativos / var / log / mysql / *.
— Dave Burt

1
nota lateral: utf8_unicode_cié melhor. Agora mesmoutf8mb4_unicode_ci
— Akshay

10

O Innodb tem uma configuração padrão (innodb_buffer_pool_size) definida como 128M - 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 adicionar o seguinte linha para /etc/mysql/my.cnf

innodb_buffer_pool_size = 16M

Eu escrevi sobre essa correção aqui http://www.mlynn.org/2012/07/mysql-5-5-on-ubuntu-12-04-job-failed-to-start


Acontece que minha VM estava simplesmente ficando sem memória. Definir um valor innodb_buffer_pool_sizemais baixo era uma parte da solução, mas cuidado, você pode estar com memória insuficiente.
— Thaddeusmt

10

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

No meu caso, o valor que eu havia 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 do mysql.

# su mysql
# mysqld

Dessa forma, você realmente vê a saída do erro.


2
Esta é uma ótima dica, eu estava lutando para obter algumas informações significativas sobre depuração do mysql. Obrigado!
— Eageranalyst

3

Eu também tive um problema semelhante. Os itens abaixo dizem que 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: http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html )

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

Perfeito! Exatamente o que estava me excitando. Obrigado.
— 25713 Jim

3

Parece se resumir a erros na configuração do MySQL, localizados em /etc/mysql/my.cnfe arquivos /etc/mysql/conf.d/.

No meu caso, era um bind-addressvalor errado , porque o endereço IP da minha máquina havia mudado e o MySQL não podia mais ligar. Sinta-se à vontade para saber mais sobre isso neste artigo do blog .


2

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

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

Isso me deu um erro de soquete:

erro: 'Não é possível conectar ao servidor MySQL local através do soquete

No meu caso, foi causado por uma userconfiguração ausente no [mysqld]grupo emmy.cnf


1

Quando tive um erro semelhante no MySQL ("O trabalho falhou ao iniciar") após a atualização de 11.10 para 12.04, comente o número 27 em https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/ 573318? Comments = tudo funcionou perfeitamente para mim. Citar:

O problema para mim foi que o arquivo /etc/apparmor.d/local/usr.sbin.mysqld não existia após a atualização. Copiei manualmente um de um dos vazios (ou seja, só tive comentários no cabeçalho) e, em seguida, estava tudo bem.


1

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

set-variable = max_connections=200

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

max_connections=200

1

Eu tive o mesmo problema. Acabou sendo a replicação do mysql my.cnf master slave. Verifique o seu /var/log/mysql/error.log.

Espero que isso ajude. Verifique as configurações do mysql primeiro antes de perder duas horas com o apparmor, que simplesmente funciona bem.


1

Eu tive os mesmos problemas, para mim o bind-addressfoi definido incorretamente no meu /etc/mysql/my.cnfarquivo. Portanto, parece que qualquer coisa que não esteja correta no my.cnf pode causar esse problema. Não encontrei nada nos logs que indicasse isso como problema.


1

Meu problema era 0% de espaço livre! Dupla verificação :-)


1

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

Eu mudo para 777 e mysqlcomeço bem.


esta coisa na antiga mas este foi o meu problema .... não sei como ele mudou ...
— TheHidden

em alguns casos, alterando o sistema de arquivos ou montando a /tmpnova partição.
— shgnInc 25/10/2015

1

Após uma atualização automática para o mysqld-5.5.53 ubuntu 14.04.1, o mysql não seria iniciado. Essas 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 com a criação deste 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

0

Apenas atualizei a versão MySQL e AppArmor, conforme sugerido aqui, para corrigir esse problema no Ubuntu 12.04 em execução na instância do Amazon ec2. Ainda recebo o erro algumas vezes, mas o MySQL se reinicia automaticamente.


1
Bem-vindo ao Ask Ubuntu! Embora isso possa teoricamente responder à pergunta, seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
— quer

0

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

innodb_force_recovery = 1

Comecei o MySQL:

sudo service mysql start

O MySQL começou e eu despejei / exportei todas as tabelas. Mudei o innodb_force_recovery para 0 (= padrão) e reiniciei o MySQL:

sudo service mysql restart

Estou usando o Ubuntu 12.04 com MySQL 5.5. Demorou muito tempo até encontrar o problema e espero poder ajudar alguém com esta resposta. Consulte também http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html


0

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

Eu mudei por cenvenience, mas 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 my.cnfpermissão era 766 e eu a alterei para 744 e dois dos três erros foram removidos. Ainda existe uma mensagem de erro semelhante, mas não impediu o mysql de iniciar.

Espero que isto ajude...


0

No meu caso, eu tive uma bind-addressdeclaração errada . Corri ifconfigpara descobrir o endereço IP privado do EC2 e o atualizei no /etc/mysql/my.cnfarquivo.


0

No meu caso, encontrei um problema de permissão em / tmp. Acabei de definir a permissão de diretório do tmp para 766 e reiniciar o serviço mysql. Corrigido.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.