LINUX.ORG.RU
ФорумAdmin

Падение MySQL

 ,


0

1

Добрый вечер.

Стал падать Mysql сервер, частота раз-два в сутки, сам не поднимается. Ошибок в логе нет. Перед тем как на коленке писать какой-то самодельный скрипт по проверке отклика с принудительным рестартом запустил его под скрином (из под root, извините).

root@xxx:~# /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
230828 19:31:07 [Note] /usr/sbin/mysqld (mysqld 5.5.62-0+deb8u1) starting as process 12345 ...
Killed
root@xxx:~#

Вот какая сволочь его kill ? В syslog на время падения ничего интересного, кроны там плановые и все такое.

у mysqld есть ключи типа verbose, debug и тд и тп
попробуй их, возможно вывод будет более многословным, чем просто killed

начни хотя бы с

mysqld --verbose --help

если маны читать не хочешь

d00fy ★★★
()
Последнее исправление: d00fy (всего исправлений: 1)
Ответ на: комментарий от firkax

А почему никто не знает, как логгирование kill-ов включить и настроить, и не советует в этом треде это сделать?

Shushundr ★★★
()
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от firkax

Да, dmesg действительно содержит некоторое количество out of memory, убивало почему-то только 2 процесса: mysqld и еще один который запущен в screen в цикле и перезапускался сразу после падения (при этом на нем это никак не сказывалось и я это даже не замечал). А вот на mysql сказывалось - он автоматически не поднимался…

Проблема таким же магическим образом и пропала. Почему убивались именно эти процессы (не трогало, например, fail2ban который тоже много кушает) не понимаю. Вопросов получается два:

  1. Как указать какие процессы нельзя трогать при OOM?
  2. Кроме как запуск mysqld в screen в цикле вместо service mysql start какие-то еще есть решения чтобы он перезапускался сам в любой ситуации?
Dima_228
() автор топика
Ответ на: комментарий от Dima_228

Ты не с той стороны заходишь.

Если у тебя OOM отстреливает БД, то надо не OOM настраивать, а срочно текущее памятью приложение фиксить/убирать. Ну или память добавлять, если версии софта сильно повысились.

Вариант «безусловно запускать БД при падении» тебе очень скоро плохо аукнется. Не должна БД убиваться OOM, данным в ней от этого хреновато может стать.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от Dima_228

Выше Dimez всё правильно написал. Решать надо не методом «Как указать какие процессы нельзя трогать при OOM?», память то все равно закончится, а узнать почему оно столько жрет. И после этого или уменьшить аппетит или добить мозгов или переписать софт в котором куча незавершающихся транзакций в виде select * from very-big-table outer join very-very-big-table outer join very-very-very-big-table или всё вместе.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от Dimez

Не должна БД убиваться OOM, данным в ней от этого хреновато может стать.

Что значит может? :)

ЗЫ И таки прикопаюсь, не БД а СУБД :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от Dimez

Может ли стать хреновато зависит от CMS и структуры базы данных. Например, живой форум на движке SMF с кучей сообщений при нештатном завершении работы MySQL по любой причине глохнет почти всегда до ручного REPAIR TABLE, форум MyBB очень редко но бывает, а DLE таким способом на моей памяти ни разу не убивалась - встала база и сайт работает как часы…

Добить мозгов невозможно. SWAP добавить тоже. Незавершающихся транзакций нет. Свободной памяти куча но вангую что проблема была в увеличении числа процессов Apache2 который стоит за Nginx. Никогда раньше такое не случалось, вот несколько дней оно мне на нервы действовало но уже прошло и больше не падает. Потому вопрос и сводится к тому как не дать убить базу. Пусть убивает лишние апачи, подумаешь очередной бот не получит контент очередной странички.

Dima_228
() автор топика