Как определить, почему MySQL перестает работать?
Недавно я обновил сервер Ubuntu до версии 16.04, и теперь MySQL внезапно останавливается через несколько часов. Он действует как бэкэнд для установки Wordpress. Моя версия MySQL сейчас:
mysql Ver 14.14 Distrib 5.5.54, for debian-linux-gnu (x86_64) using readline 6.3
Проверка who -b показывает, что сервер не перезагружался в течение нескольких дней, поэтому проблема с неправильным запуском MySQL не возникает.
Журнал /var/log/mysql/error.log пусто, как и все заархивированные.
Журнал /var/log/syslog.log не показывает ничего необычного или ссылающегося на mysql.
у меня есть unattended-upgrades установлен пакет для автоматической установки обновлений безопасности, а журнал /var/log/unattended-upgrades/unattended-upgrades.log показывает:
2017-03-22 07:00:32,459 INFO Packages that will be upgraded: libc-bin libc-dev-bin libc6 libc6-dev locales multiarch-support
2017-03-22 07:00:32,459 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
2017-03-22 07:00:38,595 INFO All upgrades installed
2017-03-22 07:00:39,846 ERROR No '/usr/bin/mail' or '/usr/sbin/sendmail',can not send mail. You probably want to install the 'mailx' package.
2017-03-22 07:00:39,846 WARNING Found /var/run/reboot-required, rebooting
указывая, что он установил некоторые обновления и запланировал перезагрузку, но еще не перезагрузился.
Как мне окончательно узнать, что привело к остановке или сбою MySQL?
Его можно остановить из-за OOM (убийца нехватки памяти). Вкратце: когда память, включая подкачку, почти полностью заполнена, ядро Linux может остановить некоторые требовательные процессы, чтобы уменьшить нагрузку на память.
Делает dmesg | grep -i oom сообщить что-нибудь?
Во-первых, я бы включил ведение журнала, так как ваш журнал ошибок mysql пуст: https://dev.mysql.com/doc/refman/8.0/en/error-log.html
Добавь это:
/etc/my.cnf # most common location
log-error=/var/log/mysqld.log
Кроме того, я бы не разрешил внешние подключения к порту 3306. Если вам нужен удаленный доступ к MySQL, используйте вместо него SSH-туннель.
Попробуйте найти что-нибудь, что убивает mysqld. Проверьте это сообщение в блоге о том, какие инструменты использовать. Auditctl сработал в одном случае, в котором я участвовал. https://www.percona.com/blog/2015/03/06/stopped-mysql-tracing-back-signals-sent-mysql/