Pgpool-II12.03.2024 20:45

63a9c8f9ea8d19fe9bacf08541b96905.png

Привет, Хабр!

Pgpool-II позволяет юзерам PostgreSQL управлять пулами соединений БД, реализовывать репликацию данных между серверами БД. Pgpool-II работает как прокси-сервер между клиентскими приложениями и серверами PostgreSQL, перехватывая запросы от клиентов и направляя их к соответствующим серверам БД согласно настроенным правилам и политикам.

Pgpool-II также поддерживает множественные режимы репликации, включая репликацию на уровне строки и репликацию на уровне транзакций. Репликация на уровне строки позволяет синхронизировать изменения данных между серверами в реальном времени, в то время как репликация на уровне транзакций сосредотачивается на синхронизации транзакций целиком.

Настроим

Установка Pgpool-II в Ubuntu и Debian: 

sudo apt-get update
sudo apt-get install pgpool2

CentOS или RHEL: 

sudo yum install pgpool-II

После установки переходим в pgpool.conf и открываем его в вашей любимой id. Базовые параметры настроек:

  • backend_hostname: здесь адреса всех узлов PostgreSQL, которые будут использоваться.

  • backend_port: порты соответствующих узлов PostgreSQL.

  • load_balance_mode: значение on, чтобы включить балансировку нагрузки.

Пример конфигурации для двух узлов: 

backend_hostname0 = '192.168.1.100'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/12/main'
backend_flag0 = 'ALLOW_TO_FAILOVER'

backend_hostname1 = '192.168.1.101'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/12/main'
backend_flag1 = 'ALLOW_TO_FAILOVER'

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

Для балансировки нагрузки чтения между узлами, данные должны быть синхронизированы. Для этого можно юзать streaming replication.

После настройки конфигурации запускаем Pgpool-II: 

sudo service pgpool2 start

Также есть прочие настройки, к примеру:

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

max_pool определяет макс. количество кэшируемых соединений к БД на каждый процесс-ребенок.

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

memory_cache_enabled — включение позволяет Pgpool-II кэшировать результаты запросов в памяти, включается так же как и все через on.

memqcache_method определяет метод кэширования, в основном юзают shmem для кэширования в общей памяти,

sr_check_period контролирует частоту проверок состояния стриминговой репликации

health_check_period — периодичность проверок состояния узлов БД.

Реплиация потокового типа

Репликация потокового типа работает на уровне байтов ипозволяет одному или нескольким серверам PostgreSQL (их называют репликами) мгновенно копировать все операции записи, выполненные на главном сервере.

На главном сервере PostgreSQL необходимо внести изменения в файл postgresql.conf: 

listen_addresses = '*'
wal_level = replica
max_wal_senders = 3

  • listen_addresses позволяет серверу принимать подключения со всех адресов.

  • wal_level устанавливается в replica для активации репликации на уровне журнала.

  • max_wal_senders указывает макс. количество одновременных соединений для отправки WAL-сегментов.

Далее, обновляем pg_hba.conf для разрешения подключений от узлов реплик: 

host replication all 192.168.1.0/24 md5

На узлах реплики настраиваем postgresql.conf аналогично и инициализируем БД с помощью pg_basebackup: 

pg_basebackup -h master_host -D /var/lib/postgresql/12/main -U replicator -v -P --wal-method=stream

В pgpool.conf, указываем главный узел и узлы реплик: 

backend_hostname0 = 'master_host'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/12/main'
backend_flag0 = 'ALLOW_TO_FAILOVER'

backend_hostname1 = 'replica_host'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/12/main'
backend_flag1 = 'ALLOW_TO_FAILOVER'

Репликация на уровне SQL-запросов

Для активации репликации на уровне SQL в pgpool.conf включаем параметры: 

replication_mode = on
replicate_select = off

  • replication_mode = on активирует репликационный режим в Pgpool-II.

  • replicate_select = off указывает Pgpool-II не реплицировать SELECT запрос

Убеждаемся, что все узлы баз данных имеют одинаковую схему и начальное состояние данных: 

# на основном узле
pg_dumpall -U postgres -s > db_schema.sql
pg_dumpall -U postgres -a > db_data.sql

# на каждом узле реплики
psql -U postgres -f db_schema.sql
psql -U postgres -f db_data.sql

Pgpool-II требует настройки мониторинга состояния узлов, чтобы корректно перенаправлять запросы и управлять репликацией: 

health_check_period = 10
health_check_timeout = 5
health_check_user = 'postgres'

  • health_check_period указывает период в секундах, через который Pgpool-II будет проверять состояние узлов.

  • health_check_timeout определяет время в секундах, после которого проверка считается неудачной.

  • health_check_user — пользователь базы данных, используемый для проверки состояния.

После настройки запускаем Pgpool-II и проверяем, что все узлы корректно обрабатывают запросы: 

pgpool -n

Чтобы проверить, что репликация на уровне SQL работает, можно выполнить операцию записи: 

INSERT INTO test_table(name) VALUES ('test');

Повышаем доступность

Pgpool-II постоянно мониторит состояние узлов PostgreSQL, используя механизмы здоровья health checks. При обнаружении отказа узла, Pgpool-II автоматически исключает его из пула обработки запросов

В pgpool.conf устанавливаем параметры для настройки проверок: 

health_check_period = 5
health_check_timeout = 3
health_check_user = 'pgpool'
health_check_password = 'pgpool_pass'
health_check_database = 'postgres'
health_check_max_retries = 3
health_check_retry_delay = 1

  • health_check_period — интервал между проверками здоровья каждого узла (в секундах).

  • health_check_timeout — время ожидания каждой проверки здоровья (в секундах).

  • health_check_user — пользователь базы данных для выполнения проверок.

  • health_check_password — пароль пользователя.

  • health_check_database — бд, в которой выполняются проверки.

  • health_check_max_retries — количество повторных попыток проверки перед объявлением узла недоступным.

  • health_check_retry_delay — задержка между повторными попытками (в секундах).

При обнаружении отказа узла, Pgpool-II может автоматически переключиться на резервный узел, если таковой настроен. ъ

Для активации и настройки автоматического переключения надо настроить failover_command в pgpool.conf, команда может включать в себя сценарий shell, который будет выполнять необходимые действия для переключения на резервный узел: 

failover_command = '/path/to/failover_script.sh %d %P %H %R'

Здесь:

  • %d — ID отказавшего узла.

  • %P — порт отказавшего узла.

  • %H — хост резервного узла.

  • %R — каталог данных резервного узла.

К примеру failover_script.sh может выглядеть примерно так: 

#!/bin/bash

failed_node_id=$1
new_primary_port=$2
new_primary_host=$3
new_primary_data_directory=$4

# логика для переключения на резервный узел, например:
echo "Failover happened. Switching to $new_primary_host:$new_primary_port."

После устранения причин отказа и восстановления узла, его можно вручную вернуть в пул Pgpool-II, используя интерфейс командной строки pcp_attach_node.

Команды сервера

pgpool — основной процесс демона Pgpool-II, который запускает и управляет самим пулом соединений. Обычно он запускается как сервис: 

pgpool -n -D

-n означает запуск в не-демонизированном режиме (полезно для отладки), а -D включает отладочный вывод.

pcp_attach_node — утилита для включения ранее отключенного узла PostgreSQL обратно в пул узлов, обслуживаемых Pgpool-II: 

pcp_attach_node -h host -p port -U username -n node_id

pcp_detach_node используется для временного исключения узла из пула Pgpool-II без остановки самого Pgpool-II: 

pcp_detach_node -h host -p port -U username -n node_id

pcp_node_info — получение информации о текущем состоянии узла в пуле Pgpool-II.

pcp_node_info -h host -p port -U username -n node_id

pcp_pool_status отображает статус пула соединений Pgpool-II: 

pcp_pool_status -h host -p port -U username

pcp_promote_node используется в конфигурациях репликации для продвижения указанного узла в роль мастера: 

pcp_promote_node -h host -p port -U username -n node_id

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

pcp_recovery_node -h host -p port -U username -n node_id

pcp_stop_pgpool останавливает Pgpool-II без остановки PostgreSQL серверов: 

pcp_stop_pgpool -h host -p port -m fast -U username

pcp_proc_info получает информацию о процессах Pgpool-II, включая активные и ожидающие соединения: 

pcp_proc_info -h host -p port -U username

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

Подробнее с pgpool-II можно ознакомиться в официальной документации.

Так как PostgreSQL входит в стек инструментов для анализа данных, хочу порекомендовать вам линейку курсов по аналитике от моих друзей из OTUS. Ознакомиться с каталогом курсов можно по ссылке.

© Habrahabr.ru