Когда базу данных стоит перенести на отдельный сервер

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

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

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

Чтобы понять, нужен ли переезд, сначала стоит посмотреть, что происходит в момент замедления:

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

Для проверки полезнее наблюдения за несколькими типичными пиками, чем один снимок загрузки. Запишите, какая операция замедлилась, сколько она выполнялась и что в это время происходило на сервере. Это позволит связать жалобу пользователя с конкретной причиной.

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

Есть и другой повод для разделения: приложение выросло до нескольких серверов. Им нужен согласованный доступ к данным. Отдельный узел базы позволяет развивать серверы приложения, не перенося данные при каждом таком изменении. При этом сама база по-прежнему требует контроля нагрузки и доступности.

Отдельный сервер для базы может быть виртуальным или физическим. При умеренной нагрузке разумно проверить вариант с VPS. Физическая машина становится интереснее при постоянной высокой нагрузке, большом объёме памяти или необходимости самостоятельно выбирать дисковую схему. Оба варианта есть у Q-DC, поэтому выбор можно привязать к результатам измерений и бюджету проекта.

При подборе конфигурации полезно подготовить несколько исходных данных:

• Память. Укажите, сколько ресурсов база использует сейчас и как меняется потребление в часы пик. Учитывайте часто используемые данные, индексы и память для обработки запросов. Объём базы на диске не равен необходимому объёму RAM.
• Накопители. Оцените скорость роста данных и запас места для журналов, временных файлов и обслуживания. Для базы важны задержки операций под нагрузкой, поэтому одной надписи «NVMe» в тарифе недостаточно.
• Процессор. Разделите две ситуации: один тяжёлый запрос выполняется слишком долго или сервер обрабатывает много запросов одновременно. Требования к производительности ядра и количеству ядер могут различаться.
• Соединение с приложением. Проверьте задержку и устойчивость сети между будущими серверами. Близость к посетителям сайта не заменяет хорошего соединения между приложением и базой.

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

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

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

Сам перенос лучше заранее отрепетировать:

1. Создать согласованную резервную копию и проверить восстановление. Для работающей базы используйте подходящий механизм резервирования СУБД. Простое копирование её файлов во время записи может дать непригодный результат.
2. Запустить копию приложения с новой базой. Проверить вход, поиск, создание записей, фоновые задания и другие важные операции. На тестовой среде нужно отключить реальные платежи, рассылки и прочие внешние действия.
3. Сравнить производительность. Повторить характерную нагрузку и измерить время пользовательских операций. Быстрый запуск пустого приложения мало говорит о поведении рабочего проекта.
4. Спланировать переключение. Определить окно работ, порядок остановки записи, переноса последних изменений и смены подключений. Учесть фоновые задачи и интеграции: они тоже могут продолжать писать в старую базу.
5. Подготовить возврат. Заранее решить, что делать при ошибке. Если новая база уже приняла заказы или другие изменения, простое переключение обратно на старую приведёт к потере доступа к этим данным.

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

Оценивать результат стоит по тем операциям, из-за которых началась работа. Открывается ли каталог во время импорта? Сохраняется ли заказ в часы пик? Укладывается ли отчёт в приемлемое время? Если эти действия стали выполняться стабильнее при сопоставимой нагрузке, у разделения есть измеримый результат.