Настройка резервных слотов в PostgreSQL-17

PostgreSQL 17 вводит failover-слоты, которые улучшают настройки высокой доступности. Слот репликации гарантирует надежность и последовательность данных между узлами во время репликации, в то время как слот failover обеспечивает согласованность между узлами, особенно во время и после сбоя.

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

Это руководство поможет вам настроить кластер PostgreSQL с высокой доступностью с использованием новой функции failover-слотов. В конце вы получите надежную настройку репликации, способную бесперебойно обрабатывать сбои.

Значение Failover-слотов с исторической точки зрения

Проблемы в PostgreSQL 15

• Слоты репликации, привязанные к основному узлу: В PostgreSQL 15 слоты репликации создавались только на основном сервере. Все логические слоты репликации терялись в случае сбоя основного сервера, что приводило к значительным задержкам в репликации и потере данных.
• Управление сбоем вручную: Во время сценариев сбоя администраторы вручную восстанавливали слоты репликации на новом основном сервере, что увеличивало сложность, вносило ошибки и продлевало время простоя.
• Нет синхронизации слотов: Сервера резервирования не имели возможности узнать о логических слотах репликации на основном сервере. Эта нехватка синхронизации привела к полному сбросу потоков репликации в случае сбоя.

Улучшения в PostgreSQL 16

Минимальное логическое декодирование

PostgreSQL 16 представил функцию под названием минимальное логическое декодирование на резервных серверах:

• Минимальное декодирование на резерве: Это позволило серверам резервирования декодировать журналы WAL для подготовки к логической репликации, позволяя использовать предварительно разогретые слоты в случае сбоя.
• Быстрый переход на резервный сервер: Предварительное декодирование изменений WAL на резерве позволило уменьшить задержку репликации при продвижении резервного сервера к основному. Однако это все еще требовало некоторой ручной настройки для обеспечения плавного перехода.

PostgreSQL 17: Игрок, изменяющий правила игры – Слоты для перехода на резервный сервер

• Слоты для перехода на резервный сервер: Введение слотов для перехода на резервный сервер в PostgreSQL 17 устраняет необходимость в ручном вмешательстве, автоматически синхронизируя логические слоты репликации между основным и резервными серверами.
• Автоматическая синхронизация: Новый работник синхронизации слотов обеспечивает, чтобы слоты, разрешающие переход (failover = true), всегда были синхронизированы, даже когда основной узел активен.
• Плавный переход: При переключении на резервный сервер он может стать основным без потери любых слотов репликации, обеспечивая нулевую потерю данных и непрерывную репликацию.

Создание кластера с высокой доступностью с резервными слотами

В этом разделе мы расскажем, как создать кластер PostgreSQL с высокой доступностью с резервными слотами. В нашем примере мы будем использовать следующие узлы:

1. NodeA (Основной сервер)
2. NodeB (Физический резервный)
3. NodeC (Логический подписчик)

Предварительные требования

Перед началом убедитесь, что у вас есть:

• PostgreSQL 17 установлен на всех трех узлах.
• Безпарольный доступ по SSH между каждым узлом.
• Базовое понимание PostgreSQL, репликации PostgreSQL и файлов конфигурации PostgreSQL.

Шаг 1: Настройка основного узла (NodeA)

1.1 Инициализировать кластер на NodeA

После установки PostgreSQL на основном узле, инициализируйте кластер; вы можете использовать следующие команды:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Настроить репликацию в файле postgresql.conf

После инициализации кластера отредактируйте файл postgresql.conf, находящийся по умолчанию в /home/pgedge/nodeA/postgresql.conf. Установите следующие значения параметров:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Обновить файл pg_hba.conf, разрешив доступ к репликации

Файл pg_hba.conf управляет аутентификацией клиента для сервера PostgreSQL. Добавьте следующую запись в /home/pgedge/nodeA/pg_hba.conf, чтобы обеспечить доступ для пользователя репликации:

host replication replicator 127.0.0.1/32 md5

Затем перезагрузите конфигурацию:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Создать пользователя репликации

Затем войдите в PostgreSQL и создайте пользователя репликации:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Создать таблицу и настроить публикацию

Затем вам нужно создать таблицу и создать связанную публикацию:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Шаг 2: Настройка физического резервного экземпляра (NodeB)

2.1 Инициализировать NodeB

После установки PostgreSQL инициализируйте NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Создать базовую резервную копию

Затем используйте pg_basebackup для создания резервной копии кластера:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Настроить postgresql.conf на Node-B

Измените файл postgresql.conf (находится в /home/pgedge/nodeB/postgresql.conf), установив:

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Включите синхронизацию слотов отказа

Используйте клиент psql для входа на NodeB:

psql -d postgres -p 5433 

Затем используйте следующие операторы для настройки репликации для NodeB:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Выйдите из клиента psql и перезапустите NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Проверьте синхронизацию слотов

Затем подключитесь к NodeB с помощью psql и убедитесь, что слоты синхронизированы:

SELECT slot_name, failover, synced FROM pg_replication_slots;

Шаг 3: Настройка логического подписчика (NodeC)

3.1 Инициализируйте кластер и настройте NodeC

После установки PostgreSQL инициализируйте кластер, вы можете использовать следующие команды:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Затем отредактируйте файл /home/pgedge/nodeC/postgresql.conf, установив следующие значения параметров:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Создайте подписку на NodeC

Используйте следующую команду для создания подписки на NodeC:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Шаг 4: Моделирование отказа и обеспечение непрерывности

Вы можете использовать следующие команды для моделирования отказа и подтверждения продолжения репликации и сохранения целостности данных.

4.1 Моделирование отказа

Используйте следующие команды для моделирования сбоя NodeA, за которым следует повышение NodeB из режима ожидания в основной:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Обновление подписки на NodeC

После продвижения узла NodeB войдите в NodeC и обновите соединение, чтобы отразить, что NodeB теперь является основным узлом:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Проверьте непрерывность данных

Для тестирования репликации используйте psql, чтобы войти в Node-B (теперь основной):

INSERT INTO foo VALUES (3), (4);

Проверьте репликацию на Node-C:

SELECT * FROM foo;

Заключение

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

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