Есть сервер, на нем крутятся сайты на php-fpm / nginx, стоит панель hestia cp (аналог Vesta cp). Каждый день примерно в одно и то же время сайты ложатся (около 10 часов по Москве). Исследовав slow query log обнаружил, что падение сайтов происходит на фоне запроса CHECK TABLE `very_big_table`;
Размер таблицы почти 200Gb. Вопрос вот в чем - непосредственно код сайтов не запускает команду CHECK TABLE. Вопрос - кто её запускает? Как этого избежать? Может ли такие запросы запускать сама база данных? Стоит 10.5.10-MariaDB. Либо же это hestia запускает? В логе медленных запросов также видно CHECK TABLE для других таблиц.
В cron-е пользователей hestia таких заданий нет на CHECK TABLE, ОС Debian
upd: Запросы CHECK TABLE выполняются от разных пользователей. Даже от тех пользователей, сайты которых не работают. Т. е., видимо, эта проверка запускается по крону либо каким-то демоном, видимо, проверяются все таблицы во всех базах данных. Но не понятно, откуда же запускается эта проверка...
В Slow Log есть и дата-время, и учётная запись, от имени которой выполнен запрос, а не только текст медленного запроса.
Кроме того, коли время повторяемо, можно включить на время General Log - и там чётко увидеть весь сеанс, из которого прилетел запрос. Как правило, этого достаточно для идентификации. А ведь параллельно можно вести мониторинги и смотреть логи других приложений и самой ОС...
В общем, проблемы-то нет. Просто надо озаботиться.
PS. Не пишите факты в комментариях - добавляйте их в текст вопроса.
Предварительно во всем "виновато" резервное копирование hestia
sudo /usr/local/hestia/bin/v-backup-users
которое запускается в 5 утра. Т. к. данных много, то "большая" таблица проверяется сильно позже. Видимо виновата строчка в файле v-backup-users
# Auto-repair all databases before backuping all accounts
mysqlrepair --all-databases --check --auto-repair > /dev/null 2>&1
Простой