MySQL не может открывать файлы после обновления сервера: errno: 24
Ubuntu: 12.04 LTS (Linux mysql02 3.2.0-40-generic # 64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux)
Ubuntu : Ubuntu distro 5.5.31
Apparmor: REMOVED!
Сервер уже более года работает на камне. Тогда в этот понедельник MySQL начал терпеть неудачу. Обновление вызвало проблему, и мы не можем понять, что это такое. Мы даже пытались вернуться к MySQL 5.5.30, но не повезло. Мы вернулись в 5.5.31.
Apparmor:
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)
Кажется, мы сталкиваемся с проблемой ulimit. Мы полностью удалили APPARMOR. Мы увеличили /etc/security/limits.conf и до сих пор не повезло:
# Out of desperation....
* soft nofile 49152
* hard nofile 65536
# No effect!?!!?
#mysql soft nofile 49152
#mysql hard nofile 65536
И чтобы показать работу /etc/security/limits.conf : [ ! d11]
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
И вот важные записи в my.cnf
[mysqld_safe]
open_files_limit = 16384
[mysqld]
open_files_limit = 16384
Однако:
root@mysql02:/etc/mysql# mysqladmin -u root -pThePassword variables| grep open_files_limit
open_files_limit | 1024
Мы полностью в тупике и вниз. Любая помощь будет принята с благодарностью.
3 ответа
Была та же проблема на Ubuntu 15.10.
https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758 - принесли решение:
проверьте, существует ли /lib/systemd/system/mysql.service или /lib/systemd/system/mysqld.service (в моем случае), если нет, создайте /lib/systemd/system/mysql.service и скопируйте контент к этому файлу https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758/comments/11 и добавить две строки где-нибудь в файлеLimitNOFILE=infinity
LimitMEMLOCK=infinity
LimitNOFILE=infinity
LimitMEMLOCK=infinity
... и все должно быть хорошо.
Как ни одна из вышеперечисленных проблем не была решена для меня (приводят только к тому, что система исчерпала память), вот решение, которое я нашел:
В /etc/mysql/my.conf вам нужно увеличить MySQLs open_files_limit. Поэтому временно добавьте это в конфигурацию и перезапустите MySQL.
[mysqld]
open_files_limit = 100000
sudo /etc/init.d/mysql restart
После запуска операции, которая дает вам слишком много ошибок открытых файлов, вы можете изменить свою конфигурацию вернуться к своему стандарту и снова перезапустить MySQL.
-
1
Спасибо за обходной путь. Но для меня проблема была омрачена двумя другими фактами.
Каталог моих данных отличается от установки по умолчанию. По нескольким причинам, как историческим, так и техническим. Я обновлялся с очень старой установки, которая проходила через несколько back-and forward-ports. При первом запуске недавно установленного MySQL 5.5 движок InnoDB не был активирован (внутренняя реализация была отключена в файле конфигурации, но плагин, который был доступен в предыдущих версиях, отсутствует в 5.5), а метка обновления была создана без фактического обновления любые таблицы.После исправления проблемы InnoDB все еще было плевок
mysql> SHOW DATABASES;
ERROR 1018 (HY000): Can't read dir of '.' (errno: 24)
Мне нужно было запустить mysqld в корневой консоли и вручную перезапустить
/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --force
Затем сервер начал показывать базы данных, но не смог получить доступ к некоторым таблицам. Спасибо, спасибо!