Переезд без валерьянки: настраиваем Zero Downtime миграцию сайта

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

Сделать миграцию бесшовной (Zero Downtime) вполне реально. Базовый принцип прост: оба сервера должны работать параллельно, пока весь трафик плавно не перетечет на новую площадку.

Шаг 1: Роняем TTL в DNS

Первое, что нужно сделать за несколько дней до запланированного переезда — зайти в панель управления DNS и радикально снизить TTL (Time To Live) для A-записей вашего домена. Ставьте минимальное значение, которое позволяет ваш регистратор. Обычно это 300 секунд (5 минут).

Если оставить дефолтные 24 часа, то после смены IP-адреса часть пользователей будет еще сутки стучаться на старый сервер, потому что их локальные провайдеры закэшировали старую запись. Нам нужно, чтобы роутинг переключался максимально быстро.

Шаг 2: Подготовка и перенос статики

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

• Настраиваем окружение на новом сервере: нужные версии PHP, Node.js, поднимаем веб-сервер, настраиваем кэширование (Redis, Memcached).
• Переносим SSL-сертификаты. Если используете Let’s Encrypt, просто скопируйте ключи со старого сервера, чтобы сайт сразу открывался по HTTPS.
• Копируем файлы проекта. Лучше всего использовать консольную утилиту rsync. Она умеет докачивать только измененные файлы. Первый прогон перенесет весь объем данных, а финальный синк перед самым переездом займет буквально пару секунд.
• Проверяем работу на новом месте. Прописываем новый IP-адрес и свой домен в локальном файле hosts на рабочем компьютере. Открываем сайт в браузере: кликаем, проверяем формы, логинимся в админку. Убеждаемся, что верстка на месте и скрипты не отвалились.

Шаг 3: Синхронизация базы данных

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

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

Сценарий 1: Master-Slave репликация (для проектов с сильной инфраструктурой)

Настраиваем старую базу как Master, а новую — как Slave. Все изменения со старого сервера на лету транслируются на новый. Когда приходит время, мы просто отключаем репликацию, делаем новую базу основной (Master) и переключаем сайт на нее. Это идеальный Zero Downtime, но он требует опыта администрирования СУБД.

Сценарий 2: Удаленное подключение (простой и надежный хак)

На новом сервере в конфигурационных файлах CMS мы временно прописываем доступы к базе данных на старом сервере (предварительно разрешив удаленное подключение в настройках MySQL/PostgreSQL). Получается изящная схема: файлы работают с нового места, а данные читаются и пишутся в старую базу. После этого мы переключаем DNS. Ждем, пока трафик полностью перейдет на новый IP. В этот момент на старый сервер уже никто не заходит. Теперь можно быстро перевести старую БД в режим Read-Only, сделать финальный дамп, развернуть его на новом сервере и поменять конфиг CMS на localhost. Даунтайм операций записи тут составит пару минут, и его легко спрятать глубокой ночью.

Шаг 4: Финальный рубильник и мониторинг

Когда файлы синхронизированы, а вопрос с базой решен, идем к регистратору и меняем старый IP на новый в A-записях домена. Благодаря тому, что мы заранее срезали TTL, трафик начнет перетекать на новую площадку почти моментально.

Что нужно делать сразу после смены IP:

• Открываем консоль и мониторим access-логи на старом сервере: поток запросов должен постепенно иссякать.
• Одновременно смотрим логи на новом сервере: трафик должен активно расти.
• Идем в Яндекс Метрику. Открываем отчеты в реальном времени и Вебвизор, чтобы убедиться, что пользователи не ловят ошибки и могут нормально взаимодействовать с интерфейсом.
• Заглядываем в Яндекс Вебмастер, проверяем ответы сервера. Инструмент проверки URL должен показывать уверенный 200 OK уже с нового адреса.

Старый сервер лучше не сносить и не отключать еще как минимум неделю. Обязательно найдется какой-нибудь забытый бот, старая интеграция по API или кэширующий узел регионального провайдера, который будет упорно ломиться по старому IP-адресу. Пусть лучше они получают ответ от старого сервера, чем отдают вашим клиентам ошибку тайм-аута.