Понимание и выполнение сценариев отработки отказа и переключения в PostgreSQL

В современной архитектуре баз данных обеспечение непрерывной работы посредством высокой доступности (HA) имеет первостепенное значение. PostgreSQL, мощная реляционная база данных с открытым исходным кодом, использует потоковую репликацию для поддержания согласованности данных между несколькими узлами. Однако, когда основной сервер сталкивается с проблемой или требует обслуживания, администраторы баз данных должны выполнять точные процедуры для восстановления работы. В этой статье четко разграничиваются две критически важные операции высокой доступности — отработка отказа (Failover) и переключение (Switchover) — и подробно описываются шаги и соображения для безопасного повышения резервной реплики до роли нового основного сервера.

Понимание различий между этими событиями жизненно важно. Переключение (switchover) — это плановый, контролируемый переход, тогда как отработка отказа (failover) — это экстренная реакция на непредвиденный сбой. Успешное управление любым из этих сценариев в значительной степени зависит от правильной конфигурации, надежного мониторинга и знакомства с инструментами, используемыми для управления репликацией.

Основы репликации: Фундамент высокой доступности

Высокая доступность PostgreSQL строится на потоковой репликации, где один сервер действует как основной (Primary или Master), а один или несколько серверов — как резервные (Standby или Replica). Основной сервер передает записи журнала предзаписи (WAL) резервным серверам для поддержания их синхронизации.

Для эффективного управления этими ролями необходимы определенные настройки конфигурации как на основном, так и на резервном узлах:

Критические настройки конфигурации

Эти настройки определяют работу репликации и то, как узлы идентифицируют друг друга:

wal_level: Должен быть установлен в replica или выше (в идеале logical, если используются инструменты, требующие логического декодирования) на основном сервере.
max_wal_senders: Определяет максимальное количество одновременных подключений от резервных серверов. Должен быть увеличен по сравнению со значением по умолчанию (обычно 10), чтобы вместить все резервные серверы.
hot_standby: Должен быть установлен в on в файле postgresql.conf резервного сервера, чтобы разрешить запросы только для чтения во время репликации.
synchronous_commit: Контролирует подтверждение транзакций. Для нулевой потери данных во время переключений (switchovers) это часто устанавливается в on (или remote_write для небольшой терпимости к задержке).
primary_conninfo: Устанавливается на резервном сервере, детализируя информацию о подключении (хост, порт, пользователь, пароль) для связи с текущим основным сервером.

Лучшая практика: Для надежной HA используйте слои пула соединений (например, PgBouncer или выделенные прокси HA, такие как Patroni или Repmgr), которые абстрагируют физические адреса серверов, делая отработку отказа и переключения бесшовными для приложений.

Переключение (Switchover): Плановый переход

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

Шаги для контролируемого переключения

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

Остановить запись на текущем основном сервере: Первым шагом является предотвращение фиксации любых новых транзакций на текущем основном сервере. Это часто достигается путем установки default_transaction_read_only = on или временного отключения клиентских соединений.
Дождаться синхронизации репликации: Убедитесь, что назначенный резервный сервер получил и применил все оставшиеся записи WAL от основного. Проверить отставание репликации можно с помощью pg_stat_replication на основном сервере или изучив статус восстановления резервного сервера.
Инициировать повышение резервного сервера: Выполните команду для повышения выбранного резервного сервера до роли основного. Конкретная команда зависит от используемого инструмента управления (например, pg_ctl promote или команда менеджера кластера).
Перенастроить старый основной сервер: После успешного повышения резервного сервера, старый основной сервер должен быть перенастроен для следования за новым основным сервером в качестве резервного. Это включает обновление его primary_conninfo.
Перенаправить приложения: Обновите балансировщик нагрузки или пул соединений, чтобы направить трафик на новый основной сервер.

Отработка отказа (Failover): Экстренное реагирование

Отработка отказа (Failover) — это немедленная, реактивная процедура, запускаемая, когда текущий основной сервер неожиданно выходит из строя (например, сбой оборудования, сетевое разделение, программная ошибка) и не может быть быстро восстановлен онлайн.

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

Выполнение экстренной отработки отказа

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

Определить состояние старого основного сервера: Убедитесь, что исходный основной сервер действительно недоступен, а не просто испытывает временную проблему с сетью (это предотвращает опасные сценарии 'расщепления мозга').
Выбрать лучший резервный сервер: Выберите резервный сервер с наименьшим отставанием репликации (тот, который дальше всех продвинулся в потоке WAL).
Повысить резервный сервер: Немедленно повысьте выбранный резервный сервер, используя команду повышения (pg_ctl promote).
Обработка потери данных (при необходимости): Если кластер использует асинхронную репликацию, данные, потерянные на отказавшем основном сервере, возможно, потребуется вручную согласовать или просто принять, в зависимости от толерантности приложения.
Перенастроить бывший основной сервер: После восстановления исходного основного сервера его необходимо очистить, переинициализировать (часто требуется базовая резервная копия с нового основного сервера) и настроить для следования за новым основным сервером.

Инструменты для безопасного повышения: Repmgr против Patroni

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

Repmgr (Менеджер репликации)

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

Переключение (Switchover): repmgr standby promote, за которым следует repmgr switchover --sibling-nodes-wait (для обеспечения синхронизации).
Отработка отказа (Failover): repmgr failover

Patroni

Patroni использует распределенные хранилища консенсуса (такие как etcd, ZooKeeper или Consul) для управления состоянием кластера, автоматически выбирая новый основной сервер при обнаружении сбоя. Patroni в значительной степени автоматизирует как переключения, так и отработку отказа с помощью вызовов API или операторов Kubernetes, значительно сокращая ручное вмешательство.

Пример использования Patroni (концептуальная команда повышения):

# Запуск переключения через REST API Patroni
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

Предупреждение о 'расщеплении мозга': Самая большая опасность при автоматической отработке отказа — это сценарий 'расщепления мозга', когда два узла ошибочно полагают, что они являются основным из-за сетевого разделения. Инструменты, такие как Patroni, смягчают это с помощью механизмов кворума, тогда как ручные настройки требуют строгих механизмов изоляции (например, управления питанием) для обеспечения существования только одного основного сервера.

Сводка различий

Особенность	Переключение (Плановое)	Отработка отказа (Аварийная)
Триггер	Обслуживание, обновление, административный выбор	Сбой основного сервера (крах, отключение)
Риск потери данных	Почти нулевой (при правильном тайминге)	От среднего до высокого (зависит от режима репликации)
Ожидаемое время простоя	Короткое, контролируемое время простоя	Немедленное, реактивное время простоя
Подготовка	Требует предварительной координации и подтверждения синхронизации WAL	Требует немедленных действий и опоры на состояние резервного сервера

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