Резервный сайт и DNS failover: когда переключение помогает, а когда теряет данные

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

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

Что делает DNS failover и чего он не решает

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

В документации Route 53 различаются active-active и active-passive. Во втором варианте основной ресурс используется штатно, а резервный предназначен для отказа основного. Эти названия описывают выбор ресурсов для ответа DNS. Они не доказывают, что базы данных настроены на правильную репликацию или что резерв уже может безопасно принимать заказы.

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

Выберите, что должен уметь резервный сайт

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

Вариант	Что он может дать	Что нужно проверить
Второе приложение с общей базой	Обслуживание при отказе одного веб-узла	Доступность общей базы и других общих зависимостей
Отдельная площадка с репликой данных	Продолжение работы после подготовленного переключения роли	Актуальность данных и единственное разрешённое место записи
Витрина в режиме чтения	Доступ к согласованному набору информации	Свежесть содержимого и отсутствие ложного приёма заказов
Информационная страница	Понятный статус и доступные способы связи	Независимость от отказавшей площадки и актуальность сообщения

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

Проверьте независимость и производительность резерва

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

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

Отдельно испытайте нагрузку, которую резерв должен принять. Если учебная площадка выдерживает 100 запросов в секунду, а после переключения ожидаются 180, наличие второго сервера само по себе не закрывает разницу. Нужны подтверждённая производительность, допустимое ограничение функций или управляемый приём трафика. Значения в этом примере условные; измерять следует свой маршрут пользователя и реальные зависимости.

Почему доступный резерв может не знать о новых заказах

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

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

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

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

Health check должен проверять готовность обслуживать клиента

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

При настройке учитывайте точную семантику инструмента. Например, Route 53 для HTTP/HTTPS проверок использует условия ответа и может искать заданную строку в его теле; HTTPS health checks при этом не проверяют действительность TLS-сертификата. Поэтому такой зелёный статус не заменяет самостоятельную проверку сертификата и результата пользовательского сценария.

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

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

Почему TTL не задаёт точное время восстановления

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

Есть и специальные режимы устойчивости DNS. RFC 8767 допускает использование устаревших данных, когда рекурсивный сервер не может обновить их у авторитетного источника. Это не означает, что любой кеш всегда игнорирует TTL. Но обещание «все посетители перейдут ровно через 60 секунд» не учитывает возможное поведение резолверов и клиентов.

Учебный пример: TTL равен 60 секундам. Первый резолвер получил основной адрес в 11:59:50 UTC; его запись истекает в 12:00:50. Отказ произошёл в 12:00:00, а авторитетные ответы начали указывать резерв с 12:00:30. Второй резолвер успел получить прежний ответ в 12:00:25 и при обычном кешировании может использовать его до 12:01:25.

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

Как не получить две одновременно пишущие площадки

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

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

Уберите из плана предположение «на старый адрес никто больше не придёт». Там могут остаться кешированные клиенты, вебхуки, административные подключения и воркеры. Защита должна действовать там, где разрешается запись или выполнение значимого действия. Переключение DNS и выключение одной кнопки на странице такой защитой не являются.

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

Изучите поведение провайдера при отказе обеих сторон

Нельзя предполагать, что DNS-сервис перестанет выдавать адрес, когда все проверки красные. Route 53 описывает защиту от каскадных отказов, при которой в последнем режиме выбора нездоровые ресурсы снова рассматриваются как допустимые. Такая логика может помочь при ошибке самих проверок, но не предоставляет приложению запрет на запись.

Для пары primary/secondary есть конкретное правило: если обе записи признаны нездоровыми, Route 53 возвращает primary. Если обычная, не alias-запись secondary не имеет health check, при нездоровом primary Route 53 выдаёт её даже при неисправном резерве. У alias-записей отдельно проверьте настройку Evaluate Target Health для оценки здоровья целевого ресурса. Эти детали нужно учитывать именно для выбранной конфигурации; поведение другого провайдера может отличаться.

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

Как выглядит подготовленное переключение

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

1. Подтверждено основание для переключения и установлена область отказа.
2. Резерв способен обслуживать выбранный режим с нужными зависимостями и нагрузкой.
3. Состояние данных оценено; неизвестные операции и допустимые ограничения явно зафиксированы.
4. Прежняя сторона не может конкурировать за запись с новой.
5. Право записи выдано согласованной стороне, если режим вообще допускает изменение данных.
6. DNS направляет новые обращения по выбранной политике, а публичный путь проверен извне.
7. На обеих площадках продолжается наблюдение за запросами, ошибками и значимыми операциями.

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

Как избежать постоянных переходов туда и обратно

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

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

Учебный пример: страница открылась, четыре заказа требуют сверки

Представим магазин с основной площадкой А и резервом Б. Перед аварией на А подтверждены четыре учебных заказа: Q201, Q202, Q203 и Q204. По журналу репликации и последующей проверке установлено, что Б ещё не содержит этих записей. Связь с А потеряна, но наличие данных на её диске пока неизвестно.

После переключения посетитель может открыть Б и не увидеть свой заказ. Нельзя объявлять запись безвозвратно потерянной только по этому наблюдению. Но нельзя и считать переход успешным для этого покупателя. Четыре ID получают статус «требуется сверка», а повторное создание заказа должно учитывать возможное наличие исходной операции и внешней оплаты.

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

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

Возвращайте основную площадку как отдельное переключение

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

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

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

Что проверить до включения автоматического режима

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

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

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

Для внешнего контроля HTTP-доступности сайта используйте SiteGuard. Готовность данных, роли площадок и безопасность переключения проверяйте по своему плану работы с резервом.