Тихие падения MariaDB: когда молчание логов скрывает критические сбои

Проблема

С января по март 2026 года мы обнаружили 6 аномальных сбросов uptime на production-сервере MariaDB 10.11.15, за которым ведёт наблюдение PmaControl. Сервер обслуживает крупные партиционированные таблицы RocksDB (метрики временных рядов).

Классический рефлекс DBA при падении: смотреть системные логи. journalctl, dmesg, /var/log/syslog. Ищем OOM, Killed process, segfault, kernel panic.

Из 6 падений только одно имело эксплуатируемый trace ядра. Остальные 5: полная тишина со стороны системы.

Метод обнаружения

Вместо того чтобы доверять системным логам, мы использовали PmaControl для обнаружения падений через временной ряд uptime:

1. Получение значений uptime через ts_value_general_int
2. Фильтрация аномальных сбросов (uptime, падающий до 0)
3. Корреляция с логами MariaDB (error.log)
4. Корреляция с journalctl для поиска сигнатур ядра
5. Анализ метрик за предыдущий час (потоки, CPU, память)

Это наиболее надёжный подход: сброс uptime + сигнатура InnoDB crash recovery = подтверждённое падение, даже без системного trace.

6 выявленных падений

Падение 6 марта: корреляция MDEV-39044

Наиболее серьёзный инцидент — 6 марта. Ошибки отличались от остальных:

RocksDB: Error opening instance, Status Code: 2,
  Status: Corruption: truncated record body
Incorrect information in file: './pmacontrol/ts_value_general_int.frm'
Can't init tc log
Aborting

Этот паттерн точно соответствует тикету MariaDB MDEV-39044: коррупция MyRocks, вызываемая:

• ALTER TABLE на крупных партиционированных таблицах RocksDB
• непрерывной высокой нагрузкой на запись
• одновременным давлением на память InnoDB

Тикет явно подтверждает, что отсутствие crash log или OOM killer является нормальным в этом сценарии.

Почему системных логов недостаточно

Из 6 инцидентов journalctl обнаружил только один эксплуатируемый trace (status=9/KILL от 12 марта).

Для остальных 5:

• нет Out of memory
• нет Killed process
• нет segfault
• нет kernel panic

Вывод прост: отсутствие сигнатуры ядра не означает отсутствие падения. Более того, это согласуется с паттерном MDEV-39044, который документирует падения без системного trace.

Что PmaControl обнаруживает, а логи нет

PmaControl непрерывно отслеживает uptime (каждые 10 секунд). Сброс = немедленное оповещение. Затем агент автоматически коррелирует:

• метрики за предыдущий час (потоки, память, CPU)
• наличие crash recovery в error log
• ошибки метаданных (.frm mismatch)

Это позволяет классифицировать инцидент даже без содействия ядра.

Рекомендации

1. Никогда не полагайтесь только на системные логи для обнаружения падений MariaDB
2. Отслеживайте uptime как первичный индикатор стабильности
3. Коррелируйте с error log MariaDB, а не с journalctl
4. Если вы используете RocksDB: ограничьте DDL-операции на крупных партиционированных таблицах, особенно под нагрузкой записи
5. Следите за MDEV-39044 для возможного исправления MyRocks

Заключение

Сервер MariaDB может упасть 6 раз за 6 недель без единой записи в системных логах. Только специализированный мониторинг баз данных — который понимает внутренние сигнатуры MariaDB — способен обнаружить и классифицировать такие инциденты.

Именно для этого создан PmaControl.