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

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.

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:

• /server/440878/changing-open-files-limit-in-mysql-5-5
• http://dev.mysql.com/doc/refman/5.5/en/server-options.html#c12634

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.

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.

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!