Pgpool-II

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

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. Ознакомиться с каталогом курсов можно по ссылке.