Администрирование MySQL/MariaDB: установка, настройка, оптимизация

Что ломается в администрировании MySQL при росте нагрузки

Деградация базы под нагрузкой редко начинается с падения: сначала отдельные выборки идут дольше, отчёт формируется минутами, потом приложение начинает ждать ответа. Причина обычно не в железе, а в настройках — буферный пул InnoDB меньше рабочего набора, и чтение уходит на диск, вставки идут по одной транзакции вместо пакетов. Симптомы размазаны по метрикам, поэтому ищут проблему уже во время сбоя.

Второй класс отказов — зависшие запросы и блокировки строк. Долгая транзакция или изменение схемы на живой таблице держат строки и метаданные, очередь ожиданий растёт, свободные соединения заканчиваются, и вместо данных приложение получает таймауты. Медленный журнал и профиль загрузки разбираем инструментами вроде pt-query-digest из набора Percona — видно, какой запрос держит блокировку и кого он тормозит.

Отдельная боль — отставание реплики. Пока ведущая пишет пакетно, подчинённый узел не успевает применять изменения, и читающий контур отдаёт устаревшие данные: отчёты, поиск и личный кабинет расходятся с основной базой. Ночное резервное копирование тоже перестаёт укладываться в окно — копия снимается дольше, а к утру диск заполнен.

Разрастание таблиц ускоряет всё перечисленное. Журналы, неархивируемые истории и временные файлы съедают место быстрее плана, изменение схемы падает на нехватке места, восстановление из копии занимает часы. По отдельности каждый пункт выглядит мелочью, вместе они превращаются в ночные инциденты. Разбираем, как это закрывается.

Что меняется после настройки: отклик, простой, отказоустойчивость

Время отклика под нагрузкой — первая метрика, по которой видно эффект. Пока схема не настроена, пиковые запросы упираются в полное сканирование таблиц и блокировки строк: отклик растёт ступенями, а к концу дня база отвечает в разы медленнее, чем утром. После настройки — индексы под фактические шаблоны запросов, выверенный размер буферного пула, лимиты соединений и разумные таймауты — отклик на 95-м процентиле держится ровно и падает в несколько раз, при этом нагрузка остаётся той же.

Отдельно измеряем время восстановления после сбоя. Настроенная репликация, регулярные резервные копии с обязательной проверкой восстановления на отдельном контуре и автоматическое переключение на реплику переводят аварию из сценария «поднимаем руками полдня» в несколько минут. Простой сервиса перестаёт быть событием недели и укладывается в целевые показатели доступности, о которых договариваемся заранее.

Уходит и целый класс отказов: переполнение диска распухшими журналами, деградация на долгих миграциях, падение из-за неограниченных соединений. Объём данных перестаёт расти линейно — партиционирование, политика хранения и очистка исторических записей держат прирост в рамках.

В результате появляется запас по ёмкости: база выдерживает рост нагрузки и добавляемый функционал без срочной замены сервера, а решения о масштабировании принимаются по метрикам, а не по факту очередного падения.

Режимы работы базы: какой вариант подходит вашей задаче

Выбор режима — это не про мощность сервера, а про профиль нагрузки и тот класс отказов, который задача готова пережить. В MySQL и MariaDB набор вариантов один и тот же, и в начале пути разница между ними почти незаметна. Проявляется она на пиках чтения, при плановом обслуживании и в момент отказа узла — там и видно, чем платят за простую схему.

Отдельно проговорим, когда режим не подходит. Если вариант выбирают под давлением разового пика, а не под профиль нагрузки, через месяц его меняют аварийно, и данные после этого сверяют вручную. Поэтому мы смотрим журнал медленных запросов, соотношение чтения и записи и допустимое окно простоя — и только потом выбираем между репликой для чтения, горячим переключением, кластером или управляемым контуром.

Как проходит внедрение: от аудита до передачи

Работы идут фиксированным порядком: сначала снимаем факты о текущем состоянии, затем проектируем целевую конфигурацию, и только потом меняем параметры. Каждое изменение опирается на замеры, а не на типовой конфиг, поэтому результат воспроизводим.

1. Аудит базы. Разбираем параметры сервера, структуру таблиц, скорость роста данных, статистику медленных запросов и историю блокировок. На выходе — список узких мест с приоритетом: что деградирует сейчас, а что проявится при росте.
2. Схема развёртывания. Определяем топологию: один узел или первичный с репликами, как распределяется чтение, где хранятся копии. Схему согласуем до установки — переделать её позже дороже, чем сразу развести нагрузку.
3. Настройка под профиль нагрузки. Считаем буферы и кэши, лимиты соединений, режим журналирования и сброса на диск под конкретный профиль: короткие транзакции, длинные аналитические выборки или смешанный поток.
4. Проверка под нагрузкой. Прогоняем сценарий, близкий к рабочему: пики записи, отчётные выборки, одновременные подключения. Смотрим не средние, а хвосты — по ним видно, когда пользователь замечает тормоза.
5. Проверка восстановления. Разворачиваем копию на отдельном узле и замеряем время до рабочего состояния с доведением до точки отказа. Пока восстановление не отработано вживую, резервная копия считается непроверенной.
6. Регламент и передача. Фиксируем мониторинг ключевых метрик, пороги алертов, порядок плановых работ и обновления конфигураций, проводим обучение команды на реальных сценариях.

Артефакты внедрения: конфигурации, схемы, регламенты

Что остаётся у заказчика после работ — не только работающий сервер, но и набор документов, по которым его сможет сопровождать любой инженер, а не только тот, кто настраивал. Конфигурации кладём в систему контроля версий с описанием изменений, схемы и регламенты — в общий репозиторий документации рядом с кодом приложения, чтобы расхождение между фактом и описанием было видно на ревью.

• Файлы конфигурации — основной конфиг сервера под контролем версий, с профилями под роль узла (мастер, реплика, узел только для чтения) и комментариями, почему параметр выставлен именно так.
• Схема развёртывания — топология узлов и потоки данных: куда пишет приложение, как расходится репликация, где точка разделения чтения и записи, что произойдёт при потере каждого узла.
• Политики доступа и роли — матрица привилегий: сервисные учётные записи с минимально необходимым набором прав, отдельные для репликации и мониторинга, операторская учётка только для чтения; секреты хранятся в менеджере паролей, а не в конфигах.
• Регламент резервного копирования — что и как часто снимается (полная копия плюс журналы изменений), срок хранения, ротация, обязательная проверка восстановления на отдельном стенде, а не «бэкап есть, значит работает».
• Инструкция по восстановлению — пошаговый порядок: остановка записи со стороны приложения, разворот копии, доведение до нужной точки по журналам, проверка целостности и сверка ключевых таблиц.
• Типовые операции — смена ведущего узла, подключение новой реплики, изменение структуры таблиц на живой базе, деградация по нагрузке: что делать и в каком порядке.
• Карта наблюдаемости — какие метрики снимаются, какие пороги считаются тревожными, кому и куда приходит оповещение.

Плюс журнал изменений: кто, когда и зачем правил конфигурацию или права — без него через полгода любая правка превращается в археологию.

Кейс администрирования MySQL: стабилизировали базу интернет-магазина

Проект — интернет-магазин с сезонными распродажами: в пик корзина и оформление заказа начинали ждать базу. На MySQL крутились и витрина, и админка, и отчёты маркетинга. Доля медленных запросов к концу дня держалась на 12-14%, аварийные перезапуски случались 5-6 раз в неделю, восстановление после падения занимало около 40 минут.

Что нашли

Основной запрос каталога выполнялся по условиям, которых в индексах не было, а часть сравнений шла с приведением типов — индекс просто игнорировался. Тяжёлые выборки за прошлые периоды запускались на том же узле, что и продажи, и вытесняли рабочий набор страниц из буферного пула. Резервные копии делались, но их никто не разворачивал: проверка восстановления вскрыла, что часть копий непригодна.

Что изменили

Пересобрали индексы под фактические планы запросов, убрали неявные преобразования типов, разбили тяжёлые отчёты на порции и увели их на отдельную реплику только для чтения. Настроили журнал медленных запросов с порогом срабатывания, чтобы деградация была видна до жалоб. Ввели регламент восстановления: раз в месяц копия разворачивается на стенде, время фиксируется, а не оценивается.

Результат до и после

Доля медленных запросов — с 12-14% до 0,3%. Время восстановления — с 40 минут до 4. Аварийные перезапуски — пять-шесть в неделю вместо нуля за последний квартал. Пиковую нагрузку распродажи выдержали двукратную к прежнему максимуму без роста времени отклика витрины.

Своя база или управляемая: что выбирать под ваш профиль

Выбор сводится не к скорости движка, а к тому, кто держит эксплуатацию. Своя база на своих мощностях даёт полный контроль: ветка MySQL, параметры буферов и соединений, планы запросов, доступ к файлам данных и логам. Управляемый контур забирает патчи, резервные копии и отказоустойчивость — взамен вы теряете часть доступа к настройкам и не выбираете время регламентных работ.

Расхождение видно по четырём осям: обновления и патчи, масштабирование, зона ответственности, трудозатраты команды.

Практическое правило: если нагрузка предсказуема и есть инженер, готовый дежурить и разбирать медленные запросы, своя база окупается свободой настройки. Если продукт растёт пиками, а команда небольшая, управляемый контур снимает дежурства и рутину — но масштабирование упирается в лимиты провайдера, а не в вашу архитектуру.

Отдельная ось — обновления. На своих мощностях минорное обновление требует окна, проверки совместимости и плана отката; в управляемом контуре его применяют по чужому графику. Поэтому критичные к простою сервисы чаще держат базу отдельно, а аналитику и внутренние системы отдают наружу.

Вопросы, которые задают инженеры перед началом работ

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

Возьмётесь за уже развёрнутую базу?

Да. Начинаем с инвентаризации: схемы, индексы, текущие параметры, расширения, регламентные задания. Изменения вносим по одному и проверяем на копии — чтобы не сломать работающие запросы.

Как убедиться, что копия действительно восстановится?

Копия без проверки восстановления копией не считается. Разворачиваем её на отдельном стенде, сверяем контрольные суммы таблиц и замеряем время восстановления до согласованного целевого показателя.

Кто отвечает за обновления безопасности?

Мы отслеживаем выпуск исправлений, тестируем их на копии и применяем по согласованному графику. Критичные патчи ставим вне очереди, но всегда с планом отката на случай регресса.

Что входит в передачу знаний?

Оставляем документацию по конфигурации, схемы репликации, регламент резервного копирования и разбор типовых аварий. Передаём всё команде заказчика — систему можно вести и без нас.

Обсудим задачу: разберём конфигурацию и вернёмся с планом

Чтобы взяться за администрирование MySQL не наугад, а по факту, нам нужен доступ к инфраструктуре и понимание, как она живёт сейчас. Сбор этого списка обычно занимает один-два дня и не требует остановки сервисов.

• Доступы к серверам. Отдельная учётная запись для наших инженеров, доступ к панели провайдера, права на чтение конфигурации — так каждое действие остаётся в логах, и вы можете его проверить.
• Текущая схема. Число узлов, топология репликации, изменённые параметры конфигурации, расписание резервных копий и когда их последний раз проверяли восстановлением.
• Профиль нагрузки. Пики по часам и дням недели, журнал медленных запросов, крупнейшие таблицы, число одновременных соединений, доля операций записи. По этим данным видно, где узкое место — в запросах, в схеме или на диске.
• Окно работ. Когда допустимы перезапуск сервиса и переключение реплик, какое время недоступности критично, есть ли регламентное окно обслуживания.
• Ограничения. Что запрещено менять, какие требования безопасности учесть, нужен ли отдельный согласующий на стороне вашей службы ИБ.
• Контакты и приёмка. Кто согласует изменения и остаётся на связи во время работ, по каким показателям считаем результат: отклик на пиках, отсутствие отставания реплик, рост объёма данных без потери скорости.

Собрав это, возвращаемся с планом работ по этапам, оценкой сроков и порядком отката на каждом шаге. Опишите задачу — начнём с разбора конфигурации и ограничений.