MySQL не може відкрити файли після оновлення сервера: errno: 24


16

Ubuntu: 12,04 LTS (Linux mysql02 3.2.0-40-generic # 64-Ubuntu SMP пн. 25 березня 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux)

MySQL: Ubuntu distro 5.5.31

Apparmor: ВІДНОВЛЕНО!

Сервер працює рок-солід вже більше року. Потім цього понеділка MySQL почав виходити з ладу. Оновлення спричинило проблему, і ми не можемо зрозуміти, що це таке. Ми навіть намагалися повернутися до MySQL 5.5.30, але не пощастило. Ми повернулися о 5.5.31.

Записи журналу помилок 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)

Здається, ми стикаємося з необмеженою проблемою. APPARMOR ми повністю видалили. Ми збільшили /etc/security/limits.conf і досі не пощастило:

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

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

І щоб показати limit.conf працює:

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

Ми повністю спотикані і вниз. Будь-яка допомога буде дуже вдячна.


1
Які повідомлення про помилки є в журналах перед тим, як надто багато відкритих файлів? Ви перезапустили mysqld після зміни open_files_limit, правда?
— Берт

так, ми повторно запускали MySQL кожного разу, коли ми вносимо зміни. У нас є одна таблиця, про яку повідомляється як про відсутню (і це чомусь): 30430 8:36:39 InnoDB: Помилка: спроба відкрити таблицю, але не вдалося InnoDB: відкрити файл просторової таблиці './oti_lw_prod/apinvoice_charges .ibd '!
— Ван

FYI, ми перевели наших користувачів до іншого головного (налаштування магістра поєдинків) севера (01), і тепер він проявляє такі самі симптоми. Він (01) мав таку саму точну конфігурацію, що і цей сервер, що вийшов з ладу (02), і це наш провал над майстром, якщо цей (02) загине. Ну, стільки для цього плану. Ми майже впевнені, що це проблема ОС.
— Ван

Я впевнений, що це не спрацювало для оригінального плаката, але для мене це сталося після оновлення безпеки, і перезавантаження mysql було достатньо.
— Kzqai

Відповіді:


19

ОС: розгортання Ubuntu (Debian)

Варіант сервера MySQL: ліміт відкритих файлів

Схоже, що Destart upstart не використовує параметри, визначені в /etc/security/limits.conf , тому коли ви запускаєте mysql через команду служби (і так, під запуском), вона переосмислює зазначені межі та використовує стандартні 1024 .

Рішення полягає в тому, щоб змінити mysql.conf файл , який визначає службу вискочки, він розташований в /etc/init/mysql.conf і додайте наступні рядки перед в передпусковому блоці:

# 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

Список літератури:


Розчарування цього десь не чітко зафіксовано. :( Ми щойно траплялися на посаді Девіда на сервері за замовчуванням.
— Ван

І це не помилка, відповідно до цього: bugs.launchpad.net/mysql-server/+bug/938669
— Ван

Це може стати раптовим і тривожним, очевидним після додавання розділів до таблиць, що може призвести до збільшення відкритих файлів.
— markdwhite

Це працювало для мене на Ubuntu 15.10. Після оновлення пакетів отримано багато повідомлень про помилки "Не вдається відкрити файл", які зламали всі мої сайти: (... Дякую мільйон за те, що врятували мені багато головного болю та часу.
— Еммануель,

хтось може пояснити, що таке блок "перед запуском"? У мене запущений Ubuntu 16 і у мене ця проблема, але файл конфігурації виглядає інакше, ніж раніше
— billynoah

4

Була така ж проблема з Ubuntu 15.10.

https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758 - приніс рішення:

  1. перевірте, чи /lib/systemd/system/mysql.service чи /lib/systemd/system/mysqld.service існує
  2. (у моєму випадку), якщо ні, створіть /lib/systemd/system/mysql.service та скопіюйте вміст цього файлу https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758/ коментарі / 11 та додайте два рядки десь у файл

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity
    
  3. якщо один або обидва файли існують, перевірте, чи включені ці два рядки:

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity
    
  4. виконати systemctl daemon-reload

... і все має бути добре.


1

Оскільки жодне з вищезгаданого не вирішило проблему для мене (це призвело лише до того, що в системі не вистачає пам'яті), ось я знайшов таке рішення:

В /etc/mysql/my.confто необхідно збільшити MySQLs внутрішньої open_files_limit. Тому тимчасово додайте це до конфігурації та перезапустіть MySQL.

[mysqld]
open_files_limit = 100000

sudo /etc/init.d/mysql restart

Після запуску операції, яка спричиняє занадто багато помилок відкритих файлів , ви можете змінити конфігурацію назад до її типової та знову перезапустити MySQL.


це працювало для мене на Ubuntu 16.04, дякую :)
— Річард Франк

0

Дякую за вирішення Але для мене питання було затьмарене двома іншими фактами.

  1. Мій каталог даних відрізняється від встановлення за замовчуванням. З багатьох причин, як історичних, так і технічних.
  2. Я модернізував дуже стару установку, яка пройшла через ряд портів назад і вперед. При першому запуску нещодавно встановленого 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

Тоді сервер почав показувати бази даних, але не маючи доступу до деяких таблиць. Ваше вирішення із збільшенням лімітів вирішило решту питань, дякую!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.