У меня Amazon t2.small EC2 - 1 ядро и 2 ГБ ОЗУ это больше, чем минимальные требования для CentOS и Virtualmin
Моя система:
Служба MySQL всегда прекращала работать месяц назад после большого количества посещений, и я могу снова перезапустить ее из Webmin, пока не прочитаю статью в блоге DigitalOcean, в которой нужно добавить [Перезагрузка = Всегда] в файле [/etc/systemd/system/multi-user.target.wants/mariadb.service] и я тестирую его, убивая процесс, после чего служба запускается снова автоматически Без остановки 22 дня
Теперь служба снова перестала работать, я открыл файл [mariadb.service] и обнаружил, что строка [Restart = Always] все еще существует, но служба остановилась случайным образом.
Примечание: я все еще могу запустить его из Webmin, без проблем, но все веб-сайты становятся недоступными из-за подключения к БД.
Мне нужно отследить эту проблему, но у меня нет опыта решения таких проблем. Как это решить?
Конфигурация MySQL: my.conf
symbolic-links=0
innodb_file_per_table = 1
myisam_sort_buffer_size = 8M
read_rnd_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
sort_buffer_size = 512K
table_open_cache = 64
max_allowed_packet = 1M
key_buffer_size = 16M
Некоторые строки из {var / log / messages}
Oct 22 16:49:49 ns1 kernel: Out of memory: Kill process 13092 (mysqld) score 97 or sacrifice child
Oct 22 16:49:49 ns1 kernel: Killed process 13092 (mysqld) total-vm:1065992kB, anon-rss:182972kB, file-rss:0kB, shmem-rss:0kB
Oct 22 16:49:49 ns1 kernel: [12822] 27 12822 28326 73 14 0 0 mysqld_safe
Oct 23 08:58:11 ns1 kernel: [12822] 27 12822 28326 74 14 0 0 mysqld_safe
Oct 23 08:58:11 ns1 kernel: [19703] 27 19703 266425 39874 150 0 0 mysqld
Oct 23 20:04:47 ns1 saslauthd[531]: do_auth : auth failure: [user=mysql] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Oct 23 22:21:25 ns1 kernel: [12822] 27 12822 28326 74 14 0 0 mysqld_safe
Oct 23 22:21:25 ns1 kernel: [19703] 27 19703 266425 48494 161 0 0 mysqld
Oct 23 22:21:25 ns1 kernel: Out of memory: Kill process 19703 (mysqld) score 103 or sacrifice child
Oct 23 22:21:25 ns1 kernel: Killed process 19703 (mysqld) total-vm:1065700kB, anon-rss:193976kB, file-rss:0kB, shmem-rss:0kB
Oct 23 22:21:25 ns1 kernel: [12822] 27 12822 28326 74 14 0 0 mysqld_safe
Oct 23 22:39:58 ns1 kernel: [12822] 27 12822 28326 76 14 0 0 mysqld_safe
Oct 23 22:39:58 ns1 kernel: [19246] 27 19246 266716 16891 98 0 0 mysqld
Oct 23 22:40:02 ns1 kernel: [12822] 27 12822 28326 76 14 0 0 mysqld_safe
Oct 23 22:40:02 ns1 kernel: [19246] 27 19246 266938 17064 98 0 0 mysqld
Oct 23 22:40:05 ns1 kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Oct 23 22:40:05 ns1 kernel: mysqld cpuset=/ mems_allowed=0
Oct 23 22:40:05 ns1 kernel: CPU: 0 PID: 19357 Comm: mysqld Kdump: loaded Not tainted 3.10.0-862.11.6.el7.x86_64 #1
Наконец, я нашел решение после 12 дней тестирования запуска MySQL после того, как он автоматически завершился сотнями посещений страниц.
Ответ зависит от вопроса System OS (CentOS) и MySQL Mariadb service
Решение: Просто добавьте несколько секунд перед запуском службы - в моем случае я добавил 45 секунд
Добавьте следующие строки в раздел [service] в {/etc/systemd/system/multi-user.target.wants/mariadb.service} - Конечно, путь зависит от вашей системной ОС и имени службы MySQL (не у всех есть mariadb.service)
Restart=always
RestartSec=45s
НЕ забывайте запускать следующие команды
sudo systemctl daemon-reload
sudo systemctl restart mariadb.service
Из этой строки в вашем журнале: Oct 22 16:49:49 ns1 kernel: Out of memory: Kill process 13092 (mysqld) score 97 or sacrifice child
Можно сказать, что вашему systemd действительно не хватило памяти и что убийца Linux OOM (Out of memory) остановил ваш процесс mysqld (демон MySQL).
Из описания Перезагрузка = раздела написано, что не перезапустится, если the service is stopped with systemctl stop or an equivalent operation, и, возможно, OOM killer является эквивалентом systemd, которого я не знаю.
Кажется, ты можешь отключить убийство OOM для вашего процесса, добавив OOMScoreAdjust=-1000 чтобы отключить эту функцию.
Без понятия. Я бы начал с рекламы обычных подозреваемых
проверьте состояние дискового пространства на всякий случай df -h и память бесплатно -m время безотказной работы (чтобы проверить сразу после сбоя)
убедитесь, что права собственности и права на каталоги данных не были изменены