Кластер высокой доступности

Кластер высокой доступности (high-availability cluster) — это группа из двух и более серверов, на которых развернуты экземпляры одной базы данных, взаимодействующие между собой по протоколу потоковой физической репликации.

В состав кластера могут входить следующие компоненты:

• Pangolin Manager – оркестратор кластера
• Pangolin DCS – распределенное хранилище конфигурации
• Pangolin Pooler – менеджер пулов соединений

Архитектура кластера высокой доступности СУБД Pangolin позволяет обеспечить соответствие требованиям к доступности, выдвигаемым к системам уровня mission critical:

• отсутствие потери данных в случае программного или аппаратного сбоя (RPO = 0);
• время простоя сервиса в случае сбоя менее 6 минут в год (RTO = 6).

Соответствие требованиям достигается за счет:

• горячего резервирования – системная репликация двух экземпляров БД в разных ЦОД (Active и StandBy);
• автоматического переключения (failover) между Active и StandBy, достигаемого средствами компонента Pangolin Manager;
• сервиса по управлению пулов соединений средствами компонента Pangolin Pooler.

Ниже приведена схема кластера из трех узлов со стеком Pangolin Manager, Pangolin DCS и Pangolin Pooler:

Поскольку физическая репликация между серверами однопоточная, в кластере всегда есть один ведущий узел (лидер), а все остальные узлы имеют статус реплики. Данные реплицируются от лидера к репликам.

Компонент Pangolin Manager использует распределенное хранилище конфигураций Pangolin DCS на базе Raft алгоритма для хранения информации о состоянии кластера, реализации механизма кворума и обеспечения идентичности значений параметров на всех узлах кластера. Pangolin Manager периодически обращается к DCS для получения информации о текущем ведущем узле (лидере), который записан в виде пары ключ-значение.

При наличии актуальной записи о лидере кластер работает в штатном режиме без изменений. Каждая запись в DCS имеет время жизни (TTL), по истечении которого запись считается неактуальной.

Если запись о лидере отсутствует или стала неактуальной, каждый экземпляр Pangolin Manager выполняет проверку доступности текущего лидера и других узлов кластера для подтверждения факта сбоя. При отсутствии ответа от лидера все узлы сравнивают свои текущие позиции журнала транзакций. Узлы с наиболее актуальной позицией «пытаются записать» информацию о себе в DCS в качестве нового лидера. Узел, который первым успешно выполнит запись, становится новым лидером кластера.

Управление кластером высокой доступности

Управление кластером осуществляется от пользователя postgres. Для часто используемых команд в файле .bash_profile пользователя postgres при автоматизированной установке определены короткие команды-алиасы.

Внимание!

Если служба Pangolin Manager активна, то управлять экземплярами СУБД Pangolin как одиночными (применяяpg_ctl, systemctl <...> postgresql) следует в режиме обслуживания (pause). Кластер может определять изменения в состоянии СУБД Pangolin как сбои и автоматически предпринимать попытки исправить состояние.

Просмотр состояния кластера (list)

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

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

Пример вывода:

+ Cluster:  $CLUSTERNAME (<cluster_id>) -----+-----------+----+-------------+-----+------------+-----+
|Member      | Host           | Role         | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
| srv1       | 127.0.0.1:5432 | Leader       | running   | 12 |             |     |            |     |
| srv2       | 127.0.0.1:5433 | Sync Standby | streaming | 12 |   0/C000000 |   0 |  0/C000000 |   0 |
+------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+

Режим обслуживания (pause)

Режим обслуживания (пауза) используется для временного прекращения управления кластером со стороны Pangolin Manager. При определенных обстоятельствах Pangolin Manager необходимо временно прекратить управление кластером, сохраняя при этом состояние кластера в DCS. Возможные случаи использования включают редкие действия с кластером, такие как обновление основной версии или восстановление после повреждения.

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

Режим обслуживания включается при помощи команды pause и выключается командой resume. Находясь в режиме обслуживания, Pangolin Manager не останавливает экземпляры и не прерывает репликацию. Продолжается постоянный опрос экземпляров (смотри параметры DCS: loop_wait, retry_timeout, ttl), но не производятся автоматические изменения состояния и конфигурации.

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

Пример использования:

1. Включение режима обслуживания:

   $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml pause $CLUSTERNAME
   
   Success: cluster management is paused

2. Выключение режима обслуживания:

   $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml resume $CLUSTERNAME
   
   Success: cluster management is resumed

Поведение в режиме паузы

Когда Pangolin Manager работает в режиме паузы, он не изменяет состояние СУБД Pangolin, за исключением следующих случаев:

• Для каждого узла ключ члена в DCS обновляется текущей информацией о кластере. Это приводит к тому, что Pangolin Manager выполняет запросы только для чтения на узле-члене, если член запущен.
• Для ведущего сервера СУБД Pangolin с блокировкой лидера Pangolin Manager обновляет блокировку. Если узел с блокировкой лидера перестает быть ведущим, понижается вручную, Pangolin Manager освободит блокировку вместо того, чтобы снова повысить узел.
• Ручной незапланированный перезапуск, ручное незапланированное переключение и повторная инициализация разрешены. Никакие запланированные действия не допускаются. Ручное переключение разрешено только в том случае, если указан узел для переключения.
• Если Pangolin Manager обнаруживает ведущие узлы с параллельной обработкой, он выдает предупреждение, но не понижает приоритет ведущего узла без блокировки лидера.
• Если в кластере нет блокировки лидера, то работающий ведущий узел получает блокировку. Если существует более одного ведущего узла, то побеждает первый ведущий узел, который получит блокировку. Если вообще нет ведущих узлов, Pangolin Manager не пытается продвигать какие-либо реплики. В этом правиле есть исключение: если нет блокировки лидера из-за того, что старый ведущий узел понизил себя из-за ручной активации, тогда только указанный кандидатный узел может получить блокировку лидера. Когда новая блокировка лидера предоставляется, после ручной активации реплики, Pangolin Manager обеспечивает, чтобы реплики, которые транслировались от предыдущего лидера, переключились на нового.
• Когда СУБД Pangolin остановлена, Pangolin Manager не пытается ее запустить. Когда Pangolin Manager остановлен, он не пытается остановить экземпляр СУБД Pangolin, которым он управляет.
• Pangolin Manager не будет пытаться удалить слоты репликации, которые не представляют другой член кластера или не указаны в конфигурации постоянных слотов.

Остановка и запуск узла (stop)

Остановка и запуск отдельного узла кластера осуществляется с помощью остановки и запуска службы pangolin-manager. При остановке службы узел корректно выходит из кластера. Если Pangolin Manager не находится в режиме обслуживания, то остановится управляемый экземпляр СУБД Pangolin.

1. Остановка службы на реплике:

   $ sudo systemctl stop pangolin-manager

2. Проверка состояния кластера:

   $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

   Пример вывода:

   + Cluster:  $CLUSTERNAME (<cluster_id>) -----+-----------+-----+-------------+-----+------------+-----+
   |Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
   +------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
   | srv1       | 127.0.0.1:5432 | Leader       | running   |  11 |             |     |            |     |
   | srv2       | 127.0.0.1:5433 | Sync Standby | stopped   |  11 |   0/C000000 |   0 |  0/C000000 |   0 |
   +------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+

3. Запуск службы на реплике:

   $ sudo systemctl start pangolin-manager

4. Проверка состояния кластера:

   $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

   Пример вывода:

   + Cluster:  $CLUSTERNAME (<cluster_id>) -----+-----------+-----+-------------+-----+------------+-----+
   |Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
   +------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
   | srv1       | 127.0.0.1:5432 | Leader       | running   |  11 |             |     |            |     |
   | srv2       | 127.0.0.1:5433 | Sync Standby | running   |  11 |   0/C000000 |   0 |  0/C000000 |   0 |
   +------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+

Обновление локальной конфигурации (reload)

Обновление локальной конфигурации выполняется с помощью команды reload. В отличие от динамической конфигурации, выполняемой при помощи команды edit-config, локальная конфигурация изменяется путем редактирования файла конфигурации Pangolin Manager. Затем выполняется команда reload, которая предписывает Pangolin Manager перечитать конфигурационные файлы, обновить конфигурационные файлы СУБД Pangolin и применить изменения. При этом на экземпляры СУБД Pangolin отправляется сигнал SIGHUP, что является аналогом pg_reload_config().

Если были изменены параметры, требующие перезапуска экземпляра СУБД Pangolin (например shared_buffers), то его можно выполнить при помощи команды restart.

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml reload $CLUSTERNAME

Пример вывода:

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+-----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Leader       | running   |  11 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Sync Standby | running   |  11 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
Are you sure you want to reload members srv1, srv2? [y/N]: y
Reload request received for member srv1 and will be processed within 10 seconds
Reload request received for member srv2 and will be processed within 10 seconds

Перезапуск узлов кластера (restart)

Перезапуск СУБД Pangolin на узлах кластера осуществляется с помощью команды restart. Операция необходима после перенастройки параметров, требующих перезапуска СУБД Pangolin.

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml restart $CLUSTERNAME

Пример вывода:

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+-----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Leader       | running   |  11 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Sync Standby | running   |  11 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
When should the restart take place (e.g. 2025-08-25T16:03)  [now]:
Are you sure you want to restart members srv1, srv2? [y/N]: y
Restart if the PostgreSQL version is less than provided (e.g. 9.5.2)  []:
Success: restart on member srv1
Success: restart on member srv2

Плановое переключение (switchover)

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

Вначале Pangolin Manager убедится, что лидер доступен, затем подберет и предложит одну из реплик на роль нового лидера (выбор можно изменить). Если подходящей реплики нет, то switchover не запустится.

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

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

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml switchover $CLUSTERNAME

Пример вывода:

Master [srv1]:
Candidate ['srv2'] []:
When should the switchover take place (e.g. 2025-08-25T16:15 )  [now]:
Current cluster topology

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Leader       | running   | 12 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Sync Standby | running   | 12 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
Are you sure you want to switchover cluster $CLUSTERNAME, demoting current master srv1? [y/N]: y
Successfully switched over to "srv2"

+ Cluster: $CLUSTERNAME (<cluster_id>) --+---------+----+-------------+---------+------------+-----+
| Member      | Host           | Role    | State   | TL | Receive LSN | Lag     | Replay LSN | Lag |
+-------------+----------------+---------+---------+----+-------------+---------+------------+-----+
| srv1        | 127.0.0.1:5432 | Replica | stopped |    |             | unknown |            |     |
| srv2        | 127.0.0.1:5433 | Leader  | running | 11 |   0/C000000 |       0 |  0/C000000 |   0 |
+-------------+----------------+---------+---------+----+-------------+---------+------------+-----+

Аварийное переключение (failover)

Аварийное переключение выполняется с помощью команды failover. Чаще всего Pangolin Manager выполняет аварийное переключение автоматически, восстанавливая доступность базы при потере лидера. Однако есть ситуации, которые требуют вмешательства администратора:

• лидер был потерян при существенно отстающих асинхронных репликах;
• в строгом синхронном режиме потерян одновременно лидер и синхронная реплика (группа реплик, если используется). Pangolin Manager не будет делать failover ни на какую реплику, кроме синхронной, при этом переключаться в асинхронный режим запрещено;
• лидер частично разрушен или нестабилен, доступность постоянно теряется и восстанавливается;
• другие ситуации.

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

Также аварийное переключение возможно выполнить в режиме обслуживания (pause).

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml failover $CLUSTERNAME

Пример вывода:

Candidate ['srv1'] []: srv1

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Sync Standby | running   | 12 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Leader       | running   | 12 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+

Are you sure you want to failover cluster $CLUSTERNAME, demoting current master srv2? [y/N]: y
Successfully failed over to "srv1"

+ Cluster: $CLUSTERNAME (<cluster_id>) --+-----------+----+-------------+-----------+------------+-----------+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag       | Replay LSN | Lag       |
+-------------+----------------+---------+-----------+----+-------------+-----------+------------+-----------+
| srv1        | 127.0.0.1:5432 | Leader  | running   | 12 |             |           |            |           |
| srv2        | 127.0.0.1:5433 | Replica | stopped   |    |             |   unknown |            |   unknown |
+-------------+----------------+---------+-----------+----+-------------+-----------+------------+-----------+

Восстановление реплики (reinit)

Восстановление/пересоздание сбойной или частично доступной реплики возможно с помощью команды reinit. Pangolin Manager автоматически останавливает реплику, проводит очистку данных, выбирает источник копии (лидер или произвольный узел из группы с меткой clonefrom), выполняет на реплике pg_basebackup с источника, запускает экземпляр, обновляет DCS, настраивает конфигурацию СУБД Pangolin и восстанавливает репликацию.

Пример использования:

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml reinit $CLUSTERNAME srv2

Пример вывода:

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Leader       | running   | 13 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Sync Standby | running   | 13 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+----+-------------+-----+------------+-----+
Are you sure you want to reinitialize members srv2? [y/N]: y
Success: reinitialize for member srv2

Дополнительные сценарии

Восстановление и контроль работоспособности

В СУБД Pangolin реализованы важные функциональности для поддержки работоспособности кластера. Подробнее в разделе «Восстановление и контроль работоспособности» данного документа.

Пересоздание узлов экземпляра СУБД

В рамках документации представлены инструкции по пересозданию узлов экземпляра СУБД Pangolin:

• Пересоздание узла арбитра
• Пересоздание узла реплики из дистрибутива
• Пересоздание узла реплики с использованием средств автоматической инсталляции