mysqldump | mysql génère l'erreur «trop de fichiers ouverts». Pourquoi?

Question

J'ai un système RHEL 5 avec un nouveau disque dur que je viens de dédier au serveur MySQL. Pour commencer, j’ai utilisé & mysqldump --host otherhost -A | mysql " ;, même si j’ai remarqué que la page de manuel ne recommandait jamais explicitement d’essayer cela (mysqldump dans un fichier n’est pas valable. Nous parlons d’une base de données de 500 Go).

Ce processus échoue à des intervalles aléatoires, se plaignant du fait que trop de fichiers sont ouverts (à quel moment mysqld obtient le signal approprié, et meurt et respawns).

J'ai essayé de le faire monter à sysctl et ulimit, mais le problème persiste. Que fais-je à ce sujet?

Answer 1

Par défaut, mysqldump applique un verrou par table à toutes les tables concernées. Si vous avez beaucoup de tables qui peuvent dépasser le nombre de descripteurs de fichier du processus serveur mysql. Essayez --skip-lock-tables ou si le verrouillage est impératif --lock-all-tables.
http://dev.mysql.com/doc/refman/5.1/en /mysqldump.html

--lock-all-tables, -x


Lock all tables across all databases. This is achieved by acquiring a global read lock for the duration of the whole dump. This option automatically turns off --single-transaction and --lock-tables.

Answer 2

Il a été signalé que

mysqldump avait résolu cette erreur pour des bases de données plus importantes ( 1 . , 2 , 3 ). Explication et solution de contournement à partir des bugs MySQL :

  

[3 février 2007 22:00] Sergei Golubchik   Ce n'est pas vraiment un bug.

     

Par défaut, mysqldump a activé --lock-tables, ce qui signifie qu'il essaie de verrouiller toutes les tables sur   être vidé avant de commencer le vidage. Et faire des tables de verrouillage t1, t2, ... pour vraiment gros   Le nombre de tables épuisera inévitablement tous les descripteurs de fichiers disponibles, car LOCK a besoin de tout.   tables à ouvrir.

     

Solutions de contournement: --skip-lock-tables désactivera complètement ce verrouillage. Alternativement   --lock-all-tables obligera mysqldump à utiliser FLUSH TABLES WITH READ LOCK qui verrouille tout   tables dans toutes les bases de données (sans les ouvrir). Dans ce cas, mysqldump sera automatiquement   disable --lock-tables car cela n'a aucun sens d'utiliser --lock-all-tables.

Modifier : vérifiez la solution de contournement de Dave pour InnoDB dans le commentaire ci-dessous.

Answer 3

Si votre base de données est aussi volumineuse, vous avez quelques problèmes.

1. Vous devez verrouiller les tables pour vider les données.

2. mysqldump prendra très très longtemps et vos tables devront être verrouillées pendant ce temps.

3. L'importation des données sur le nouveau serveur prendra également beaucoup de temps.

Etant donné que votre base de données sera essentiellement inutilisable pendant que les n ° 1 et n ° 2 se produisent, je vous recommande en fait d'arrêter la base de données et d'utiliser rsync pour copier les fichiers sur l'autre serveur. C'est plus rapide que d'utiliser mysqldump et beaucoup plus rapide que d'importer, car vous n'avez pas l'IO et le CPU ajoutés pour générer des index.

Dans les environnements de production sous Linux, de nombreuses personnes placent des données Mysql sur une partition LVM. Ensuite, ils arrêtent la base de données, réalisent un instantané LVM, démarrent la base de données et copient à leur guise l'état de la base de données arrêtée.