Início / dba / Perguntas / 46180
Accepted
700 Software
Asked: 2013-07-12 11:31:53 +0800 CST

Erro raro dura apenas um segundo "Não é possível conectar ao servidor MySQL local através do soquete '/tmp/mysql.sock' (146)" 146=ECONNREFUSED

  • 772

Este é um erro raro que ocorre no Solaris 10, vi isso no Perl, onde esta linha
DBI->connect(...) or die "Whoops! $DBI::errstr"

saídasWhoops! Can't connect to local MySQL server through socket '/tmp/mysql.sock' (146) at something.pl line ...

Eu determinei que no meu sistema, 146=ECONNREFUSED

É muito raro que esse erro ocorra, mas acontece continuamente.
É sempre um problema temporário nesta configuração - durando apenas um ou dois segundos.

A variável global max_connectionsfoi descartada como um problema.

Isso não ocorre em conexões baseadas em TCP/IP.

Estou usando a [mysqld_safe] log-erroropção em my.cnf. O log mostra o seguinte na inicialização:
mysqld started
InnoDB: Started; log sequence number...
[Note] .../libexec/mysqld: ready for connections.
Version: '5.0.27-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
Não há outras entradas de log, então não há nada aqui para indicar o problema.

Por favor, deixe-me saber se você pode sugerir uma configuração para registro mais detalhado.

Você pode enumerar as causas possíveis ou prováveis ​​desse erro acontecendo apenas ocasionalmente e apenas por um ou dois segundos ?

mysql errors

1 respostas

  1. Best Answer

    A vida tem muitos grandes mistérios. Para o MySQL DBA, um dos maiores mistérios da vida é a sua pergunta . Tem sido assim há 12 anos. Na verdade, encontrei um relatório de bug que foi resolvido quando o desaparecimento de mysql.sockfoi causado pela tentativa de iniciar o mysqld com o mysqld já em execução (também conhecido como Shooting mysqld in the Foot) .

    Eu tratei pessoalmente de soluções alternativas para esta situação muitas vezes no StackExchange:

    O mistério tem a ver com mysql.sock(o arquivo MySQL Socket) desaparecendo. Quando isso acontecer, você não poderá se conectar ao mysqld usando root@localhost. Na verdade, nenhum usuário definido com host='localhost'na mysql.usertabela pode se conectar. Conexões TCP/IP ainda podem ser usadas. A solução alternativa é conectar-se ao mysqld usando TCP/IP.

    Tente criar o usuário root@'127.0.0.1'. No cliente mysql, você faz o seguinte:

    mysql -uroot -p -h127.0.0.1 --protocol=tcp

    A única maneira de trazer de volta mysql.socké reiniciar o mysqld QUANDO o mysqld NÃO ESTÁ EM EXECUÇÃO.

    Você deve certificar-se de definir explicitamente o mysql.sockarquivo em/etc/my.cnf

    [mysqld]
socket=/var/run/mysqld/mysql.sock

    Claro, vá criar a pasta

    mkdir /var/run/mysqld
chmod 777 /var/run/mysqld

    De uma chance !!!

    ATUALIZAÇÃO 2013-12-06 10:17 EST

    Com base nos seus comentários...

    Eu incluí o log, por favor, deixe-me saber se você sabe como aumentar o detalhe

    Você está usando o MySQL 5.0.27, o que significa que você está usando um mysqld muito antigo (com um monte de bugs) e um antigo InnoDB Storage Engine. Pode não haver detalhes adicionais disponíveis. Também observei que você está usando uma distribuição de origem em vez de binários instalados por RPM.

    trazer de volta o mysql.sock é reiniciar o mysqld. Isso não acontece comigo. Eu nunca tenho que fazer nada. O problema dura um segundo e desaparece.

    Se o problema persistir por apenas um segundo ou dois, posso ver o que está acontecendo. Quando você executa o serviço mysql start, na verdade você está executando mysqld_safe. Na parte inferior do mysqld_safe, existe um loop infinito. No loop infinito, ele chama mysqld e espera por um valor de retorno. Certos valores de retorno do mysqld farão com que o mysqld_safe termine (desligamento normal, condição em que o mysqld não pode iniciar novamente). Outros valores de retorno farão com que mysqld_safe faça um loop e tente mysqld novamente.

    SUGESTÃO

    Você deve atualizar para o MySQL 5.6 para obter a versão mais recente mysqlde o InnoDB Storage Engine. Se o problema persistir, pelo menos haverá menos bagagem devido a binários MySQL de melhor qualidade. Dessa forma, você pode descartar o mysqld e procurar outros fatores externos. Além disso, você deve baixar os binários do RPM em vez de compilar o código-fonte porque a versão do RPM geralmente possui mais otimizações.

    ATUALIZAÇÃO 2013-12-06 10:39 EST

    Se você olhar os dois links no topo da minha resposta

    você aprenderá que o primeiro link faz referência ao MySQL 4.0.20 e o segundo link foi de um tópico de relatório de bug que dizia que a versão em questão era MySQL 3.22.32 (a versão final do MySQL 3 era 3.23.58)

    Problemas com mysql.sockjá duram cerca de 13 anos devido a um tiro no próprio pé (iniciando o mysqld mesmo estando em execução), fatores internos (versão muito antiga ou versão desajeitada do MySQL) ou alguma condição externa (falta de RAM ou outros recursos do sistema operacional) .

    Então, parece que você encontrou um fator interno. Para verificar se o mysqld está se corrigindo, execute SHOW GLOBAL VARIABLES LIKE 'uptime';. Se o número continuar aumentando e nunca reiniciar, então você pode culpar o binário desajeitado do MySQL por não ser mais elaborado. A MySQL AB provavelmente estava resolvendo algum problema interno e pode ter deixado algumas instruções de depuração ou pontos de rastreamento no binário

    ATUALIZAÇÃO 2013-12-06 11:24 EST

    Apenas olhei dentro do mysqld_safe. Existe um código para imprimir mysqld terminado e mysqld reiniciado. Se mysqld realmente terminou, mysqld_safe o teria registrado. Se o mysqld foi reiniciado pelo mysqld_safe, a nova/nova instância do mysqld imprimiria as informações de log incluindo o número da versão. Como o número da versão foi impresso apenas uma vez, fica claro que o mysqld nunca foi finalizado e nunca reiniciado. – George Bailey 13 minutos atrás

    Apenas para sua informação, descobri que 146 é ECONNREFUSED, editei na minha pergunta. – George Bailey 11 minutos atrás

    Então, parece que você encontrou um problema interno. O mysqld MySQL 5.0.27 compilado em fonte pode estar apenas imprimindo mensagens de depuração após uma recuperação interna. Para verificar mysqldse está tudo bem em termos de funcionamento, basta executar SHOW GLOBAL VARIABLES LIKE 'uptime';. Se o número não reiniciar e apenas continuar aumentando, então o mysqld está se corrigindo por dentro. Dada a compilação antiga que você está usando e a forma como foi compilado, eu não esperaria que o mysqld fosse mais acessível por conta própria.

    Você deve ver se o mysqld foi iniciado com a depuração habilitada. Caso contrário, tente definir o debug my.cnfe veja se ele pode ser mais detalhado sobre seus componentes internos . Espero que isso revele qual pode ser o problema.

    • 4

relate perguntas