Eu tenho batido minha cabeça contra esta por alguns dias agora. Temos duas semanas de snapshots de backup diários de nosso diretório de dados mysql de produção (ou seja, os arquivos binários reais, não dumps de sql) e eu preciso restaurar uma tabela de um dos backups para que possamos compará-lo com o que temos agora .
Então eu criei um diretório de esquema fictício e extraí os arquivos de tabela relevantes (.MYI, .MYD e .frm) e reiniciei o mysql. Ele aparece, eu posso "mostrar tabelas", mas se eu tentar interagir com ele de qualquer forma ("desc tablename", "select ...", etc) eu recebo:
Can't find file: './schema_name/table_name.frm' (errno: 13)
[ed: nomes reais são higienizados]
Errno 13 é permissões, então eu verifiquei tudo novamente. O diretório e os arquivos possuem o mesmo dono e grupo (mysql: mysql) que todos os outros esquemas. Eles também têm o mesmo perms (700 no dir, 660 nos arquivos). Olhando para "ls -n", os uids também combinam exatamente.
Mais recentemente, tentei fazer um extrato completo de um backup diferente e, em seguida, vinculá-lo ao diretório de dados mysql (não há espaço suficiente nesse volume para extrair a coisa completa) e recebo o mesmo erro. Eu também tentei apontar o diretório de dados do mysql em my.cnf para o diretório que está mantendo o backup e reiniciando. Ele construiu as tabelas mysql que precisavam estar lá, mas eu ainda tenho o mesmo erro.A única coisa que posso encontrar no googling são pessoas que tiveram esse problema por causa de erros reais de propriedade ou permissão, o que não parece ser o caso para mim. Eu também encontrei algumas observações sobre uma variável env do UMASK que pode resultar nesse erro, mas acho que tem a ver com instalações novas, o que não é.
Você está executando algo como o selinux ou algum outro pacote semelhante? Eu sugiro desabilitar isso (ou modificar as políticas de segurança) para ver se algo está impedindo o MySQL de acessar os arquivos.
[edit] Em caso afirmativo, verifique o syslog para ver se o selinux está bloqueando o mysql de fazer qualquer coisa. Se é o SELinux, me disseram que isso pode desativá-lo para que você possa testar essa teoria.
/usr/sbin/setenforce Permissive
strace é seu amigo neste caso. Encontre o id do processo do seu mysql e execute:
strace -efile -f -o /tmp/mysql.log -p $pid
Em outra janela, faça algo que cause o erro. Você pode então pressionar ctrl-c para matar strace. Se você olhar em /tmp/mysql.log, deverá ver o que causou o problema.
Como um aparte, eu realmente recomendo que você não dependa de copiar os arquivos de dados binários. Os despejos de SQL são muito mais confiáveis e flexíveis. Além disso, parece que você está usando o MyISAM. Eu realmente recomendaria contra usá-los a menos que você não se importe com os dados neles. O InnoDB tem tantas vantagens sobre o MyISAM.
Recentemente tive esse problema, e resolvi isso alterando a permissão do diretório de banco de dados de todos do diretório do banco de dados localizado em /var/lib/mysql , assim:
PWD: /var/lib/mysql
chmod u+x schema_db1
chmod u+x schema_db2
chmod u+x schema_db3
chmod u+x schema_db4
Reinicie o mecanismo do MySQL e está funcionando novamente! Espero que isso funcione para você.
Quando me deparei com esse problema antes, era porque os arquivos não eram de propriedade do usuário mysql, independentemente de suas permissões. chmod 777 não é realmente algo que você deseja executar em um diretório de dados editado por um servidor.
Verifique qual é o nome de usuário configurado em /etc/my.cnf
[mysqld]
bind-address=<IP Address>
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=<username>
Pode ser raiz ou que você configurou. Eu modifiquei para root e ele começou a trabalhar para mim.
Em seguida, inicie o mysql
service mysqld stop
service mysqld start
Tags mysql