Manque de ressources pour mysqldump

J'essaie de faire un mysqldump sur un serveur Windows et j'obtiens le message d'erreur suivant :

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

Voici la commande que j'exécute:

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

Le redémarrage du service mysql n'a pas aidé.

Je reçois toujours le message pour la même table.

J'ai essayé de réduire les variables table_cache et max_connections de 64 à 32 et 30 à 10 respectivement, mais je ne reçois toujours l'erreur que cette fois pour une table différente (et à partir de maintenant le message d'erreur mentionne toujours la deuxième table).

Le même script s'exécute sans problème sur une douzaine d'autres serveurs Windows ayant la même base de données.

Toutes les bases de données ont 85 tables.

Selon ici - "OS error code 24: Too many open files" qui correspond à l'erreur plus générale 23 "Out of resources".

Il semble donc que vous manquiez de descripteurs de fichiers. Il s'agit généralement d'un paramètre / problème côté serveur, soit dans MySQL, soit dans le système d'exploitation lui-même.

Peut-être vérifier / ajuster le --open-files-limitparamètre dans MySQL lui-même et voir si cela aide.

Aussi, essayez peut-être d'exécuter le vidage, alors que personne d'autre n'utilise la base de données, avec le --single-transactionparamètre au lieu de --Lock-File, car plusieurs personnes suggèrent que cela fonctionnera une table à la fois au lieu de les ouvrir toutes en même temps (donc en utilisant moins de descripteurs de fichiers).

Au-delà de cela, vous devrez probablement trouver une cause profonde expliquant pourquoi ce serveur particulier manque de ressources. Ce qui impliquerait probablement le dépannage en désactivant autant de services / processus que possible et de voir si le vidage passe. Ensuite, déterminez à partir de là qui est le coupable qui mange trop de ressources et ne les libère peut-être pas correctement.

Êtes - vous une position pour essayer avec au --single-transactionlieu de --lock-tablespar exemple les tables sont InnoDB et que vous n'utilisez des tables de cluster et ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE ne se produire pendant la décharge? Il est préférable de confirmer que cela convient à votre organisation d'assistance MySQL si vous en avez une.

J'ai seulement essayé ceci sur unix mais fondamentalement si j'essaye avec une base de données avec 2000 tables il échoue avec une erreur similaire à la vôtre par exemple j'ai utilisé tous mes descripteurs de fichiers ouverts.

Vous pouvez obtenir cette erreur:

MySQL: Errcode: 24 lors de l'utilisation de LOCK TABLES

... ainsi que d'autres erreurs lorsque vous effectuez une mise à niveau vers MySQL 5.5 et que vous exécutez vos sauvegardes sur Plesk ou tout autre système d'exploitation en cours d'exécution mysqldump.

Pour corriger:

1. modifier my.cnf

2. Ajouter:

   open_files_limit=2048
   

3. Redémarrez MySQL

Si vous recevez:

Impossible de charger depuis mysql.proc. Le tableau est probablement corrompu (1548)

Ceci est le résultat d'une mise à niveau vers 5.5. Exécuter:

mysql_upgrade --force

Testé et travaillé sur CentOS 6.7 et Plesk 12.

J'ai eu un problème similaire à celui de Philipe. Lorsque je démarre le vidage, j'ai vu une erreur comme celle-ci:

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

J'ai utilisé une commande simple:

mysqldump -uroot -p c1baznarz > c1baznarz.sql

Donc, j'ajoute une autre commande à mon mysqldump:

--single-transaction

et le vidage est prêt. Donc, ma requête tout mysqldump ressemble à ceci:

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