MySQL ne peut pas ouvrir de fichiers après la mise à jour du serveur: errno: 24


16

Ubuntu: 12.04 LTS (Linux mysql02 3.2.0-40-generic # 64-Ubuntu SMP lun 25 mars 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux)

MySQL: distribution Ubuntu 5.5.31

Apparmor: SUPPRIMÉ!

Le serveur fonctionne comme un roc depuis plus d'un an. Puis ce lundi, MySQL a commencé à échouer. Une mise à jour a causé le problème et nous ne pouvons pas le déterminer. Nous avons même essayé de revenir à MySQL 5.5.30 mais sans succès. Nous sommes revenus à 5.5.31.

Entrées du journal des erreurs MySQL:

130430  7:55:46 [ERROR] Error in accept: Too many open files
130430  7:55:46 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/fclvod.frm' (errno: 24)
130430  7:55:46 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/fcnote.frm' (errno: 24)
130430  7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffcont.frm' (errno: 24)
130430  7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffcontv.frm' (errno: 24)
130430  7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffnote.frm' (errno: 24)
130430  7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/frcfcl.frm' (errno: 24)

Il semble que nous rencontrons un problème ulimit. Nous avons supprimé complètement APPARMOR. Nous avons augmenté le /etc/security/limits.conf et toujours pas de chance:

# Out of desperation....
* soft  nofile  49152
* hard  nofile  65536

# No effect!?!!?
#mysql  soft  nofile  49152
#mysql  hard  nofile  65536

Et pour montrer que le limites.conf fonctionne:

root@mysql02:/etc/security# ulimit -Sa | grep "open files"
open files                      (-n) 49152

root@mysql02:/etc/security# ulimit -Ha | grep "open files"
open files                      (-n) 65536

Et voici les entrées importantes dans my.cnf

[mysqld_safe]
open_files_limit = 16384

[mysqld]
open_files_limit = 16384

Pourtant:

root@mysql02:/etc/mysql# mysqladmin -u root -pThePassword variables| grep open_files_limit
open_files_limit                                  | 1024

Nous sommes totalement perplexes et déprimés. Toute assistance sera grandement appréciée.


1
Quels messages d'erreur y a-t-il dans les journaux AVANT celui sur Trop de fichiers ouverts? Vous avez redémarré mysqld depuis la modification de open_files_limit, non?
Bert

oui, nous avons redémarré MySQL chaque fois que nous apportons des modifications. Nous avons une table qui est signalée comme manquante (et c'est pour une raison quelconque): 30430 8:36:39 InnoDB: Erreur: tentative d'ouverture d'une table, mais impossible InnoDB: ouvrez le fichier d'espace de table './oti_lw_prod/apinvoice_charges .ibd '!
Van

Pour info, nous avons déplacé nos utilisateurs vers notre autre serveur maître (configuration duel master) (01) et il présente maintenant exactement les mêmes symptômes. Il (01) avait la même configuration exacte que ce serveur défaillant (02) et est notre maître de basculement si celui-ci (02) venait à mourir. Eh bien, tant pis pour ce plan. Nous sommes à peu près sûrs que c'est un problème de système d'exploitation.
Van

Je suis sûr que cela n'a pas fonctionné pour l'affiche originale, mais pour moi, cela s'est produit après une mise à jour de sécurité, et le redémarrage de mysql était suffisant.
Kzqai

Réponses:


19

OS: déploiements Ubuntu (Debian)

Option de serveur MySQL: open-files-limit

Il semble que Debian upstart n'utilise pas les paramètres définis dans /etc/security/limits.conf , donc lorsque vous lancez mysql via la commande de service (et donc, sous upstart), il remplace ces limites définies et utilise la valeur par défaut 1024 .

La solution consiste à modifier le fichier mysql.conf qui définit le service upstart, il se trouve dans /etc/init/mysql.conf et ajouter les lignes suivantes avant le bloc de pré-démarrage :

# NB: Upstart scripts do not respect
# /etc/security/limits.conf, so the open-file limits
# settings need to be applied here.
limit nofile 32000 32000
limit nproc 32000 32000

Les références:


Décevant, cela n'est pas clairement documenté quelque part. :( Nous venons de tomber sur la publication de David sur une erreur de serveur.
Van

Et ce n'est pas un bug, selon cela: bugs.launchpad.net/mysql-server/+bug/938669
Van

Cela peut devenir soudain et alarmant, après avoir ajouté des partitions aux tables, ce qui peut entraîner une augmentation des fichiers ouverts.
markdwhite

Cela a fonctionné pour moi sur Ubuntu 15.10. Après la mise à niveau des packages, j'ai reçu des tonnes de messages d'erreur "Impossible d'ouvrir le fichier", qui ont cassé tous mes sites: (... Merci mille fois de m'avoir épargné beaucoup de maux de tête et de temps.
Emmanuel

quelqu'un peut-il expliquer ce qu'est le bloc "pré-démarrage"? J'utilise Ubuntu 16 et j'ai ce problème mais le fichier de configuration est différent de ce qu'il était auparavant
billynoah

4

Eu le même problème sur Ubuntu 15.10.

https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758 - a apporté la solution:

  1. vérifier si /lib/systemd/system/mysql.service ou /lib/systemd/system/mysqld.service existe
  2. (dans mon cas) sinon, créez /lib/systemd/system/mysql.service et copiez le contenu de ce fichier https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758/ commentaires / 11 et ajoutez les deux lignes quelque part dans le fichier

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity
    
  3. si un ou les deux fichiers existent, vérifiez si ces deux lignes sont incluses:

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity
    
  4. exécuter systemctl daemon-reload

... et tout devrait bien se passer.


1

Comme rien de ce qui précède n'a résolu le problème pour moi (ne conduisait que le système à manquer de mémoire), voici la solution que j'ai trouvée:

Dans /etc/mysql/my.confvous devez augmenter open_files_limit interne à MySQL. Alors ajoutez temporairement ceci à la configuration et redémarrez MySQL.

[mysqld]
open_files_limit = 100000

sudo /etc/init.d/mysql restart

Après avoir exécuté l'opération qui vous donne l' erreur de fichiers ouverts trop nombreux , vous pouvez rétablir votre configuration par défaut et redémarrer MySQL à nouveau.


cela a fonctionné pour moi sur Ubuntu 16.04, merci :)
Richard Frank

0

Merci pour la solution de contournement. Mais pour moi, la question a été éclipsée par les deux autres faits.

  1. Mon répertoire de données est différent de l'installation par défaut. Pour de multiples raisons, à la fois historiques et techniques.
  2. J'étais en train de mettre à niveau à partir d'une très ancienne installation, qui passait par un certain nombre de ports arrière et avant. Au premier démarrage d'un MySQL 5.5 nouvellement installé, le moteur InnoDB n'était pas activé (l'implémentation interne a été désactivée dans le fichier de configuration, mais le plugin qui était disponible dans les versions précédentes n'est pas présent dans 5.5), et la marque de mise à niveau a été créée sans réellement mettre à niveau toutes les tables.

Après avoir corrigé le problème InnoDB, il crachait toujours

mysql> SHOW DATABASES;
ERROR 1018 (HY000): Can't read dir of '.' (errno: 24)

J'ai dû démarrer mysqld dans la console racine et redémarrer manuellement

/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --force

Ensuite, le serveur a commencé à afficher les bases de données, mais n'a pas pu accéder à certaines tables. Votre solution de contournement avec des limites accrues a résolu le reste des problèmes, merci!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.