MySQL error #2002 – No such file or directory

Ainda configurando meu ambiente de trabalho no Mac OS X, me deparei com um problema que eu não conhecia no MySQL: Error #2002 – No such file or directory.

O arquivo nao encontrado é o MySQL socket, então seu PHP está apontando para um arquivo de socket inexistente.

O primeiro passo é descobrir onde está o mysql.socket, para isso você precisa estar com o MySQL server rodando e abrir um terminal do MySQL. No terminal do MySQL digite status, e você terá informações parecidas com estas:

Connection id: 4 
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.5.28 MySQL Community Server (GPL)
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /tmp/mysql.sock
Uptime: 42 min 26 sec

O UNIX socket mostra o local correto do seu arquivo de socket, agora você só precisa fazer seu PHP apontar para este mesmo arquivo. Abra seu PHP.ini e procure pelos atributos listados abaixo, substituindo pelo valor correto (o do status no terminal do seu MySQL):

  • pdo_mysql.default_socket
  • mysql.default_socket
  • mysqli.default_socket
  • pdo_mysql.default_socket

Agora é só reiniciar seu Apache para aplicar as novas configurações e você estará apto a conectar ao MySQL com o PHP.

Dúvidas e sugestões nos comentários. 🙂

XAMP e MySQL no Mac – XAMPPErrorDomain error

Como tenho pouca experiência com Mac OS, quem configurou meu ambiente de desenvolvimento foi meu colega Well, que optoiu pelo XAMPP para a configuração do Apache e MySQL.

Hoje percebi que o MySQL não estava iniciando, e retornava o erro "XAMPPErrorDomain error 1", que pelo que pesquisei é um erro de permissão apenas.

 

XAMPPErrorDomain error 1

Não sei se esta mensagem de erro dá para outros casos, mas no meu caso ela representava um problema de permissão de execução nos arquivos do MySQL.

A solução foi dar um chmod -R 777 na pasta do MySQL do XAMPP:

sudo chmod -R 777 /Applications/XAMPP/xamppfiles/var/mysql

Pronto, agora é só iniciar o MySQL através do XAMPP Controle e ele deve funcionar corretamente.

 

phpMyAdmin

Vi que o MySQL estava com o processo rodando corretamente mas quando tentei acessar o phpMyAdmin recebi o seguinte erro: 

#1 - Can't create/write to file '/Applications/XAMPP/xamppfiles/temp/#sql274_1_2.MYI' (Errcode: 13)

Novamente problema de permissão de escrita na pasta indicada, outro chmod:

sudo chmod -R 777 /Applications/XAMPP/xamppfiles/temp

Problema resolvido, MySQL rodando e phpMyAdmin funcionando corretamente. Resolveu este problema de outra forma? Compartilha nos comentários para eu manter o post atualizado. 🙂

Como fazer o restore de um dump do MySQL?

Em outro post eu expliquei como agendar backup (dump) do MySQL com shellscript, agora vou explicar como fazer um "restore" desses dados.

Quando você faz um dump ou um "export" pelo PHPMyAdmin, ele gera um arquivo .sql, o comando abaixo vai ler esse SQL e executar ele no banco indicado.

Supondo que você tenha gerado um dump chamado "dump.sql", para inserir isso no banco chamado "andafter", faça o seguinte:

Fazendo restore do MySQL no terminal

mysql -u root -p andafter < dump.sql

No exemplo acima meu usuário (parâmetro -u) é "root", e o parâmetro -p pede que a senha solicitada após o comando (para que a senha não fique gravada nos comandos do terminal). O nome do banco é "andafter" e ele irá executar o dump.sql.

Import no PHPMyAdmin

Pelo PHPMyAdmin acesse o banco que vai receber a importação e clique em Import.

Selecione o arquivo sql que você vai usar para importar os dados (lembre-se que existe um limite de upload setado no PHP, o padrão é 2Mb, se o dump ultrapassr o limite do servidor você precisa fazer este processo ou em partes ou por terminal).

Clique em GO e aguarde, a importação aqui é um pouco mais lenta do que pelo terminal.

MySQL – innoDB e MyISAM

Quando nós viramos a nova versão do And After 2011 sofremos algun dias com problemas de performance – o MySQL que rodava no servidor funcionava normalmente por algum tempo (aleatório) e o consumo de processamento subia loucamente, o site parava de responder e logo o servidor morria. Um reset, e o ciclo voltava a acontecer…

Testei alguns métodos de cache: geração de html, cache de query mas nada foi muito satisfatório – ou quando resolvia o problema prejudicava um pouco a navegação e usabilidade do site (login, publicação de comentários, etc.).

O @fefurst e um pessoal do Twitter falou para eu verificar como estavam configuradas as tabelas do meu banco e falaram para eu tentar converter para MyISAM (o atual padrão de tabelas do mysql) – mas elas já estavam neste formato.

Alterei tudo para innoDB e o problema de performance acabou – o MySQL parou de derrubar o processador e o tempo de resposta voltou ao normal, ouf!

Principais diferenças entre innoDB e MyISAM

InnoDB usa proteção por registro (row locking) enquanto MyISAM usa proteção por tabelas (table locking), por isso em tabelas que são constantemente alteradas (é o caso de algumas tabelas do And After, com as tabelas de logs, comentários, etc) o InnoDB apresenta uma melhor performance do que o MyISAM – que em outros casos é melhor que InnoDB pois não funciona com transações.

Para tabelas usadas essencialmente para consultas (como tabela de localidades, ou de usuários de um sistema fechado) o MyISAM é o mais recomendado.

Dicas de performance com MySQL

Cache

Outra dica para performance – que o Chrisimplementou aqui no And After – é verificar a existência de querys complexas na sua aplicação e pensar em alguma forma de cache para estas querys. Usamos isso na tagcloud, acompanhem a lógica para confirmar a tagcloud:

  1. Percorrer todas as tags do banco
  2. Verificar quantos posts estão associados a cada tag
  3. Ordenar as tags de acordo com o número de posts que utilizam

Essa query é um pouco lenta, tem alguns innerjoins malucos e não é legal ter ela em quase todas as telas. Uma opção é configurar o cache do próprio MySQL, outra opção (que foi o que fizemos) é transformar esta query em uma rotina e criar uma segunda tabela para a tagcloud OU adicionar uma coluna na tabela de tags que representa a relevância daquela tag (no exemplo, o número de posts que a utilizam).

Indexação de buscas

Esta aí algo que eu não posso falar muito pois ainda não tenho familiaridade: sistemas de indexação de busca. Só conheço o Lucene – sei que funciona com o Zend (EN)  e tem como fazer isso funcionar com o Code Igniter (EN) – mas para aplicações com muita informação é uma opção que deve ser considerada com carinho.

Antes de sair por aí alterando coisas em produção verifique se está tudo certo com o agendamento de backup do seu MySQL.

Referências

Backup do MySQL com shell script

Desde a migração do And After (final de dez 2010) para sua nova versão eu não tinha nenhuma rotina de backup do MySQL rodando – e já aprendi que nunca nesta vida devemos ficar sem backup do banco de dados de nossos projetos ou clientes.

Como eu sou "dummie" no Linux (veja você que cheguei a escrever como ver o IP no Linux) eu não sabia como fazer o agendamento de tarefas até descobrir como usar o crontab para agendar rotinas e executar shell scripts.

Ontem pesquisei um pouco sobre a melhor forma de executar um backup do MySQL e as recomendações em fóruns era de que a forma mais correta de fazer um backup sem a necessidade de derrubar o serviço é usando o mysqldump.

O MySQL dump

O mysqldump acessa sua base de dados como qualqer aplicação, por isso não é necessário derrubar o serviço antes do backup. Se você optar pela cópia de arquivos do sistema ao invés do dump (e não derrubar o mysql antes do backup) pode acontecer problema nos arquivos caso sua base seja alterada durante o backup.

O comando para gerar um .sql usando o  mysqdump é recebe algumas variáveis, um exemplo do comando (as variáveis estão explicadas abaixo do comando):

mysqldump -h localhost -u usuario -pSUASENHA nomedabase > meubackup.sql

Todos os itens sublinhados são variáveis e você deve alterar de acordo com as configurações do seu servidor.

localhost – o servidor para acessar o banco MySQL

usuario – o nome do usuário do banco

SUASENHA – password do usuário setado na variável acima (repare que não existe espaço entre -p e a senha digitada

nomedabase – nome da base que será exportada

meubackup.sql – nome do arquivo que será salvo (incluir a extensão .sql)

O arquivo gerado irá ser salvo no local em que o comando foi executado, portanto você deve primeiro ir até a pasta onde você quer salvar seu backup (usando o comando cd), por exemplo:

cd /var/backups/mysql

Feito isso você executa o comando mostrado anteriormente e será gerado o arquivo dentro de /var/backups/mysql.

Shell script para fazer o mysqldump

Sabendo os comandos para executar o dump do MySQL tudo o que você precisa agora é passar estes comando para um arquivo .sh (shell script).

Requisitos e/ou configurações

  • Ubuntu Server 10
  • gzip instalado (sudo apt-get install gzip)
  • MySQL rodando (com possibilidade de executar o mysqldump)
  • Usuário/senha com acesso a base mysql

Não estou dizendo que só vai funcionar na versão do SO que estou passando aí, mas como cada versão tem suas peculiaridades a informação pode ser importante para quem tiver problemas. 😉

#/bin/bash
U_PASTA="/var/backup/mysql"
U_DATA=$(/bin/date +%Y%m%d%H%M%S)
U_CAMINHO="backup-$U_DATA.sql"
U_HOST="localhost"
U_USER="root"
U_PASSWORD="password"
U_DATABASE="database"
#
cd $U_PASTA
mysqldump -h $U_HOST -u $U_USER -p$U_PASSWORD $U_DATABASE > $U_CAMINHO
gzip $U_CAMINHO
echo "Backup do MySQL executado"
 

No início do código as definições das variáveis para o comando mysqdump e também é salvo uma variável com informações de data, que é usada para nomear o arquivo sql gerado.

A lógica do código:

  1. Vai para o caminho especificado onde será salva a exportação do banco
  2. Executa o mysqldump com as configurações das variáveis
  3. Compacta o arquivo exportado (gzip, não mantém o arquivo descompactado)

Meu post anterior foi um tutorial sobre como usar crontab, com ele é possível você criar uma rotina que executa o seu shell script e mantém seus dados seguros. Para o And After criei uma tarefa diária, toda a madrugada uma cópia do banco é salva.

Cuidado!

O shell script deste post apenas gera os backups e não trata os backups antigos. Se você fizer a exportação diária do banco e não tratar de alguma forma seus backups consumirão todo o espaço do seu servidor.

Existem exemplos em que o próprio shell script e exclui os arquivos antigos, achei mais prático deixar isso a cargo do logrotate (que é assunto para outro post).