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

Настройка PostgreSQL HA: где именно ломается отказоустойчивость

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

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

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

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

Что даёт отказоустойчивый PostgreSQL на практике

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

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

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

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

Варианты отказоустойчивого кластера: сравнение режимов

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

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

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

Порядок внедрения: аудит, схема, репликация, проверка

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

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

Что передаём на руки: конфигурации, схемы, регламенты

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

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

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

Как сократили простой: замеры до и после на живом кластере

До: каждый сбой будил дежурного

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

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

После: переключение за десятки секунд

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

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

Что делать, если кластер уже развёрнут на одной машине?

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

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

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

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

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

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

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

Зачем в кластере арбитр?

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

Как убедиться, что переключение сработает?

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

Реплика заменяет резервную копию?

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

Сколько простоя занимают плановые работы?

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

Обсудим задачу: схема, сроки, план внедрения

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

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

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