Автоматический перезапуск MySQL, когда он умирает

Question

У меня есть сервер стойки, который я арендовал для запуска моих личных проектов. Так как я дешевый, он имеет 256 Мб оперативной памяти и, честно говоря, не может справиться много. Время от времени, когда происходит резкое увеличение трафика, сервер решает запустить процессы уничтожения, и кажется, что mysqld является популярным средством для уничтожения. Я пытаюсь зайти на свой сайт и получаю сообщение о том, что произошла ошибка при установлении соединения с базой данных. Проверка журналов показывает, что mysqld был убит из-за нехватки памяти.

Так как я все еще беден, как и вчера, и не хочу обновлять оперативную память моей виртуальной машины в стойке, есть ли способ, с помощью которого я могу сказать ей автоматически перезапускать mysqld после его смерти?

У меня есть мысль использовать что-то вроде crontab, но, увы, я точно не знаю, что там делать. Я предполагаю, что я являюсь продуктом поколения "Linux на вашем компьютере", так как я могу делать большинство вещей на своем настольном компьютере и ноутбуке (которые работают почти исключительно под Linux), но все еще не хватает навыков администрирования сервера для Linux.

Сервер работает CentOS 6.3

Answer 1

Это не чистое решение, было бы лучше, во-первых, избежать этой проблемы. Во всяком случае, я не уверен, как CentOS управляет сервисами, но я думаю, что он использует service . Если это так, вы можете проверить, работает ли служба mysql с

/sbin/service mysql status

Эта команда успешно завершится, если mysql работает, и вернет состояние выхода не 0, если я не. Поэтому вы можете запустить службу, если она не работает с этой командой:

/sbin/service mysql status || service mysql start

Вы можете добавить эту строку в /etc/crontab для запуска команды thes каждую минуту:

* * * * * /sbin/service mysql status || service mysql start

Answer 2

Это немного беспокоит.

mysqld всегда перезапускается mysqld_safe, потому что в нижней части mysqld_safe есть бесконечный цикл для проверки на ненормальное завершение работы. Если ошибка слишком серьезная, даже mysqld_safe не сможет перезапустить mysqld при последующих попытках.

Учитывая ту ситуацию, для которой разработано mysqld_safe , может быть не очень хорошей идеей принудительно запустить mysqld если mysqld_safe все равно отклонит его.

Вам нужно найти журнал ошибок в my.cnf, он будет находиться под

[mysqld]
log-error=log-filename

или же

[mysqld_safe]
log-error=log-filename

Прочитайте текстовый файл (возможно, запустив tail -30 log-filename) и найдите источник завершения обработки mysqld.

Answer 3

В попытке грубой силы сохранить работоспособность VPS с низким объемом памяти я использовал модификацию ответа terdom для проверки и перезапуска MySQL.

/sbin/service mysqld status || service mysqld restart

Мне нужно изменить mysql для mysqld , чтобы заставить его работать. Без этого я бы получил ошибку « ERROR! MySQL is running but PID file could not be found ".

В моей системе CentOS 7.2 /sbin/service перенаправляет в состояние /bin/systemctl status , поэтому следующая команда выполняется быстрее.

/bin/systemctl status  mysqld.service || /bin/systemctl start  mysqld.service

В итоге я добавил следующую строку в корневой каталог системы. Он проверяет каждую минуту, работает ли MySQL, и перенаправляет стандартный вывод на ноль. Запуск службы не выдаст ничего, если что-то пойдет не так, поэтому нет необходимости добавлять нулевое перенаправление в последнюю команду.

* * * * * /bin/systemctl status mysqld.service > /dev/null || /bin/systemctl start  mysqld.service

Двойная труба || означает « OR и выполнит вторую команду, если первая команда каким-то образом потерпит неудачу. (Возвращает код выхода больше нуля.)

Это все равно что сказать: «Выполнить 1-ю команду или, если 1-я команда каким-то образом потерпит неудачу, запустить 2-ю команду».

Это не похоже на двойной амперсанд && который похож на высказывание: «Запустите 1-ую команду, и, только если 1-я команда была успешной, запустите 2-ю команду».

Answer 4

Следующее от jonnyreeves.co.uk :

---

И виновник php-fpm! Быстрый Google нашел другого клиента Wordpress, страдающего от подобных симптомов; Совет состоял в том, чтобы настроить конфигурацию пула php-fpm (/etc/php-fpm.d/www.conf) и настроить конфигурацию pm. Основное изменение состояло в том, чтобы перейти от pm = dynamic к pm = ondemand со значением pm.max_children равным 5 (на основе наблюдения за ~ 5% использования памяти на одного работника). После изменения конфигурации я перезапустил все сервисы и проверил использование памяти.

service php-fpm restart
service nginx restart
service mariadb restart

После перезапуска использование памяти было резко ниже.