Sem recursos para o mysqldump

Estou tentando fazer um mysqldump em um servidor Windows e recebo a seguinte mensagem de erro :

mysqldump: Got error: 23: Out of resources when opening file '.\db\sometable.MYD' (Errcode: 24) when using LOCK TABLES

Aqui está o comando que estou executando:

mysqldump -u user -p"pass" --lock-tables --default-character-set=latin1 -e --quick databasename > "query.sql"

Reiniciar o serviço mysql não ajudou.

Eu sempre recebo a mensagem para a mesma mesa.

Eu tentei reduzir os table_cache e max_connections variáveis de 64 a 32 e 30 a 10, respectivamente, mas eu ainda obter o erro só que desta vez para uma tabela diferente (e de agora em diante a mensagem de erro é sempre mentionning a segunda tabela).

O mesmo script está sendo executado em uma dúzia de outros servidores Windows com o mesmo banco de dados sem problemas.

Todos os bancos de dados possuem 85 tabelas.

De acordo com aqui - "Código de erro do SO 24: Muitos arquivos abertos", alinhados com o erro mais geral 23 "Sem recursos".

Portanto, parece que você está ficando sem identificadores de arquivo. Geralmente, isso é configuração / problema no final do servidor, no MySQL ou no próprio sistema operacional.

Talvez verifique / ajuste a --open-files-limitconfiguração no próprio MySQL e veja se isso ajuda.

Além disso, talvez tente executar o dump, enquanto ninguém mais estiver usando o banco de dados, com a --single-transactionconfiguração em vez de --Lock-File, pois várias pessoas sugerem que isso funcionará uma tabela por vez, em vez de abri-las todas de uma vez (portanto, usando menos identificadores de arquivo).

Além disso, você provavelmente precisará encontrar uma causa raiz do motivo pelo qual esse servidor específico está ficando sem recursos. O que provavelmente envolveria a solução de problemas, desativando o maior número possível de serviços / processos e ver se o dump passava. A partir daí, descubra quem é o culpado que está consumindo muitos recursos e talvez não os liberando corretamente.

Você está em posição de experimentá-lo em --single-transactionvez de, --lock-tablespor exemplo, as tabelas serem do InnoDB e não usar tabelas de cluster e que ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE não ocorrerão durante o despejo? É melhor confirmar que está tudo bem com a sua organização de suporte ao MySQL, se você tiver uma.

Eu só tentei isso no unix, mas basicamente, se eu tentar com um banco de dados com 2000 tabelas, ele falha com erro semelhante ao seu, por exemplo, eu usei todos os meus identificadores de arquivos abertos.

Você pode receber este erro:

MySQL: Errcode: 24 ao usar LOCK TABLES

... junto com outros erros ao atualizar para o MySQL 5.5 e você estiver executando seus backups no Plesk ou em qualquer outro sistema operacional em execução mysqldump.

Consertar:

1. Editar my.cnf

2. Adicionar:

   open_files_limit=2048
   

3. Reinicie o MySQL

Se você estiver recebendo:

Não é possível carregar do mysql.proc. A tabela provavelmente está corrompida (1548)

Isso é resultado de uma atualização para o 5.5. Executar:

mysql_upgrade --force

Testado e trabalhado no CentOS 6.7 e Plesk 12.

Eu tive um problema semelhante ao Philipe. Quando inicio o dump, vi um erro como este:

mysqldump: Got error: 23: Out of resources when opening file './c1baznarz/timecard.MYD' (Errcode: 24) when using LOCK TABLES

Eu usei comando simples:

mysqldump -uroot -p c1baznarz > c1baznarz.sql

Então, adiciono outro comando ao meu mysqldump:

--single-transaction

e despejo está pronto. Então, minha consulta todos mysqldump se parece com isso:

mysqldump -uroot -p --lock-tables --single-transaction c1baznarz > c1baznarz.sql