Отказоустойчивость PostgreSQL: цена архитектурных решений

Репликация не равна отказоустойчивости

В PostgreSQL 17 резервный сервер можно поднять из потока WAL, но база данных не решит за вас, когда переключать трафик, как исключить запись в старый primary и что делать, если реплики разошлись по состоянию. Архитектура определяет не только время восстановления, но и то, может ли приложение продолжать запись при проблемах с сетью.

Ниже — разбор решений для PostgreSQL 17. Основные компромиссы применимы и к PostgreSQL 16, но настройки и детали поведения проверяйте по документации именно вашей версии. Это не инструкция по установке конкретного менеджера кластера: выбор и настройка такого инструмента зависят от инфраструктуры.

Термины. RPO — сколько данных допустимо потерять после аварии. RTO — сколько времени допустимо восстанавливать сервис. Нулевые значения обоих показателей не возникают от одного факта наличия реплики: их нужно обеспечить и проверить в сценариях отказа.

Сначала задайте цену отказа

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

• Какие операции должны пережить аварию? Уточните, относится ли требование ко всем транзакциям или только к подтверждённым пользователю.
• Сколько потери данных приемлемо? При асинхронной репликации отстающая реплика может не получить последние записи primary.
• Как быстро нужно восстановиться? Время обнаружения сбоя, принятия решения, продвижения реплики и переподключения клиентов складывается в общий RTO.
• Можно ли временно остановить запись? Синхронная репликация способна обменять доступность записи на более строгую сохранность подтверждённых транзакций.

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

Три схемы и их архитектурная цена

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

Реплика отвечает на вопрос «где есть копия данных». Отказоустойчивость — ещё и ответ на вопрос «кто имеет право принимать запись, когда связь нарушена».

Что меняется в системе после выбора схемы

Синхронная репликация связывает запись с сетью

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

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

Асинхронная репликация переносит риск в момент переключения

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

Контролируйте не только состояние «реплика подключена», но и объём и время отставания, скорость получения и применения WAL. Большое отставание может возникнуть из-за проблем сети, медленного диска или нагрузки на реплику. Восстановление связи не гарантирует, что реплика догонит primary быстрее, чем тот генерирует новый WAL.

Автоматическое переключение требует fencing

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

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

Переключение — это ещё и контракт с приложением

После смены primary клиенты должны перестать писать в старый адрес и установить соединения с новым. Если адрес базы зашит в конфигурации приложений или соединения долго живут в пуле, продвижение реплики само по себе не восстановит сервис. Проверьте DNS или прокси, пул соединений, повторные попытки и таймауты.

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

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

Что измерять и как проверять граничные случаи

До запуска зафиксируйте исходные значения под реальной для сервиса нагрузкой, а после изменений сравнивайте их на одинаковом сценарии. Не объявляйте систему отказоустойчивой по успешному тесту «выключили primary»: он не проверяет все сетевые разделения и сбои дисков.

• Отставание реплики по времени и объёму WAL, включая время, необходимое ей для догоняющего применения.
• Задержку подтверждения транзакций до и после включения синхронного режима.
• Время от обнаружения отказа до восстановления чтения и записи со стороны приложения.
• Поведение при потере primary, standby, связи между узлами и связи с системой управления.
• Состояние старого primary после переключения: может ли он принимать записи или гарантированно изолирован.
• Результат восстановления из резервной копии и WAL, включая потерю всего основного кластера.

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

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

Что делать дальше

Начните с короткого документа: RPO, RTO, допустимость остановки записи, география узлов и ответственный за ручное вмешательство. Затем выберите режим репликации и способ управления failover, отдельно описав fencing и перенаправление клиентов. Только после этого настраивайте кластер.

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