Миграция на сервер без простоя: ошибки и защита

Переезд на сервер большего размера без простоя — это не перенос архива и не смена IP-адреса в DNS. Пока пользователи открывают сайт, в базу продолжают записываться заказы, платежи и сессии. Если переключить трафик в неподходящий момент, часть данных окажется на старом сервере, а часть — на новом. Ниже — схема для Linux-серверов с Ubuntu 24.04 LTS, Nginx 1.24+ и PostgreSQL 16; принцип подходит и для других стеков, если у них есть механизм репликации или синхронной доставки данных.

Что вы меняете на самом деле

При миграции есть минимум четыре независимых слоя:

• вычислительные ресурсы: CPU, RAM, диски и сетевой канал;
• приложение: исходный код, зависимости, переменные окружения и фоновые задачи;
• данные: база, загруженные файлы, очереди и кэш;
• маршрутизация: DNS, балансировщик или прокси перед серверами.

Увеличить размер виртуальной машины проще всего: провайдер временно выключает инстанс, меняет его конфигурацию и запускает снова. Это короткий простой, но не миграция без остановки. Настоящий zero-downtime-переезд требует, чтобы старый сервер продолжал обслуживать запросы до тех пор, пока новый не пройдет проверку.

Без простоя не означает «переключить за одну секунду». Это означает заранее подготовить новый контур, передать ему данные и сохранить возможность вернуть трафик назад.

Три подхода и их цена

Выбор зависит от того, что именно хранит приложение и насколько быстро меняются данные. Перед началом посчитайте объем базы, скорость записи, объем пользовательских файлов и допустимую потерю данных. Последний показатель называют RPO^[1].

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

Рабочая схема переезда

1. Опишите зависимости до создания нового сервера

Составьте карту: домены, DNS-записи, база, хранилище файлов, cron-задачи, очереди, SMTP, платежные уведомления, внешние API и сертификаты. Отдельно выпишите все сервисы, которые обращаются к старому IP-адресу напрямую. Такие ссылки часто остаются в настройках мониторинга, webhook-адресах и разрешенных списках доступа.

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

2. Подготовьте новый контур отдельно от боевого

Установите ту же операционную систему или совместимую версию, Nginx, PostgreSQL 16, рантайм приложения и системные зависимости. Не обновляйте одновременно сервер, базу и приложение без отдельного плана: если миграция сломается, вы не поймете, какой компонент стал причиной.

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

Проверка: новый сервер отвечает по временному домену или через локальную запись hosts, а приложение проходит health-check без подключения к боевому трафику.

3. Запустите синхронизацию данных

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

Смотрите не только на статус «реплика работает». Важны задержка репликации, ошибки применения изменений, свободное место и количество записей, которые еще не дошли до нового узла.

Проверка: контрольный запрос показывает одинаковые данные на старом и новом сервере, а тестовый файл доступен из нового контура.

4. Проверьте приложение на копии боевого трафика

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

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

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

5. Подготовьте короткое окно переключения

Заранее снизьте TTL DNS, но не рассчитывайте, что все пользователи обновят адрес через это значение: резолверы и приложения могут кэшировать ответы дольше. Надежнее переключать не сам серверный IP, а запись на балансировщик или прокси, где старый и новый контуры уже описаны как отдельные upstream.

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

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

6. Не удаляйте старый сервер сразу

Оставьте старый контур доступным, но не принимайте на нем обычный трафик. Зафиксируйте время переключения и наблюдайте за ошибками, задержками, нагрузкой на CPU и диски, платежными уведомлениями и обращениями пользователей. Конкретную длительность окна отката определите по вашему RPO и скорости изменения данных: если на новом сервере появились записи, простой возврат маршрута уже может привести к расхождению.

Типичные ошибки, из-за которых возникает простой

• Копируют базу один раз. Пока архив восстанавливается, в боевой базе появляются новые строки. Перед переключением нужна репликация или короткая контролируемая пауза с финальной синхронизацией.
• Забывают про файлы. База переехала, но изображения, документы или каталоги сборки остались на старом диске. Пользователь видит битые ссылки уже после смены маршрута.
• Меняют DNS и считают задачу законченной. Часть клиентов продолжает ходить на старый адрес из-за кэша. Система должна некоторое время корректно обслуживать оба маршрута либо переключаться через общий прокси.
• Запускают cron на двух серверах. Две копии обработчика могут создать дубли заказов, писем и задач. Фоновые процессы нужно разделить, заблокировать или перевести на очередь с защитой от повторной обработки.
• Проверяют только главную страницу. Главная может открываться, пока не работают авторизация, загрузка файла, платежный callback или запись в базу. Нужен сценарный smoke-тест, а не один HTTP-код 200.
• Не тестируют откат. Если новый сервер не принимает запись или ломает внешнюю интеграцию, команда начинает искать инструкцию в момент инцидента. План возврата должен быть отдельным пошаговым документом.

Где схема ломается

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

Вторая граница — несовместимые версии. Обновление PostgreSQL, PHP, Node.js или формата файлов может изменить поведение приложения даже при одинаковой конфигурации. Сначала добейтесь совместимости, затем меняйте версию отдельной задачей.

Третья — внешние системы. Платежный провайдер или почтовый сервис может отправлять callback на старый URL независимо от DNS. Проверьте адреса уведомлений, сертификаты и списки разрешенных IP до переключения.

^[1] RPO — Recovery Point Objective, допустимый объем данных, который можно потерять при сбое. RPO равен нулю только тогда, когда вы обеспечили доставку всех подтвержденных записей на новый контур.

Что сделать после переезда

В первые часы смотрите не только на доступность сайта. Сравнивайте долю ошибок, p95-задержку, количество запросов к базе, задержку репликации, заполнение диска, очередь фоновых задач и число успешных бизнес-операций. Метрики до и после нужно сравнивать при сопоставимой нагрузке, иначе вывод о результате будет случайным.

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