Настройка PostgreSQL высокой доступности через Patroni под ключ

Почему падает PostgreSQL высокой доступности при отказе узла

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

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

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

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

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

Что даёт отказоустойчивый кластер: измеримый эффект

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

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

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

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

Варианты организации PostgreSQL: сравнение подходов

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

Выбор определяется двумя числами: допустимым временем недоступности и допустимым объёмом потерянных транзакций. Там, где потери недопустимы, мы собираем кластер с автоматическим переключением ролей (Patroni) и синхронным резервом, а горячий резерв оставляем под чтение и отчётность.

Этапы внедрения: аудит, схема, настройка, проверка, передача

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

1. Аудит конфигурации. Снимаем параметры Patroni, параметры репликации, схему размещения узлов по зонам доступности, поведение пулера соединений и приложений при обрыве связи с мастером. На выходе — перечень точек отказа и оценка, какое время недоступности кластер даёт сейчас.
2. Проектирование схемы переключения. Определяем число узлов и кворум, режим синхронной репликации, порядок выбора нового лидера, роль арбитра и целевое окно переключения. Фиксируем, что происходит с транзакциями, которые не успели доехать до реплик.
3. Сборка стенда. Разворачиваем копию целевой топологии, прогоняем нагрузку и сценарии отказов. Здесь же проверяем совместимость с текущими версиями приложений и корректность строк подключения.
4. Настройка на боевых узлах. Вводим узлы поэтапно, с реплик на мастер, чтобы в любой момент оставалась точка возврата. Настраиваем проверки живости, таймауты, автоматическое восстановление отставшей реплики.
5. Проверка отказов. Убиваем мастер, рвём сеть между зонами, замедляем диск, отключаем узел хранилища состояний — и смотрим, как кластер ведёт себя без вмешательства. Каждый сценарий повторяем, пока результат не станет предсказуемым.
6. Передача в эксплуатацию. Отдаём регламент планового переключения, дашборды и оповещения, порядок действий при потере кворума, инструкцию по возврату конфигурации к прежнему состоянию. Проводим разбор с командой заказчика на живом стенде.

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

Конфигурации, схемы переключения и регламенты эксплуатации

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

• Конфигурации всех узлов — файлы Patroni, параметры PostgreSQL, настройки DCS: в репозитории с историей изменений, а не разложены по серверам. Любая правка проходит ревью и откатывается одной ревизией.
• Схема топологии — какие узлы, где синхронная реплика, какие точки отказа есть и что происходит при потере узла или хранилища состояния.
• Политики доступа — роли и права, разделение приложения и администрирования, порядок выдачи доступов дежурным и ротация учётных данных.
• Резервное копирование — расписание полных и инкрементальных копий, глубина хранения, непрерывная архивация журналов и отметка, до которой гарантированно восстанавливаемся.
• Регламент эксплуатации — плановое переключение, окна обслуживания, обновление на репликах, действия при потере узла и критерии эскалации.
• Инструкции для дежурных — пошаговые сценарии с командами и проверками: что дежурный делает сам, а на каком шаге вызывает инженера.
• Документация кластера — схема восстановления после сбоя, результаты учебных прогонов и журнал изменений с ответственным за каждое.

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

Кейс: как ручное переключение заменили автоматическим

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

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

Метрики до и после

• Аварийные переключения: 5-6 в квартал → 2-3, ни одного ночного разбора.
• Время восстановления записи: около сорока минут → меньше минуты.
• Ложные вызовы дежурного: сократились примерно вдвое.

Что изменилось в дежурной смене

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

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

Чем автоматический выбор лидера отличается от ручного переключения?

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

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

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

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

Технические сомнения: репликация, переключение, обслуживание

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

Приложение встанет на время переключения?

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

Как вы проверяете резервные копии?

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

У нас уже развёрнут кластер — перестраивать всё заново?

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

Обсудим задачу: вернёмся с оценкой и планом работ

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

В ответ присылаем комплект, по которому можно принимать решение:

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

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