PostgreSQL в Termux: настройка репликации, резервного копирования с pgBackRest и горизонтального масштабирования с pgpool-II

Выполните base backup с primary:

pg_basebackup -h 192.168.1.10 -p 5432 -D ~/pgdata -U repl_user -Fp -Xs -P

Дальше нужно включить режим standby. В современных версиях PostgreSQL применяется подход с standby.signal и настройкой primary_conninfo.

Создайте файл:

touch ~/pgdata/standby.signal

Отредактируйте postgresql.auto.conf или recovery.conf (в зависимости от версии). В современных версиях часто удобно через postgresql.auto.conf. Пример:

nano ~/pgdata/postgresql.auto.conf

Добавьте:

primary_conninfo = 'host=192.168.1.10 port=5432 user=repl_user password=STRONG_PASSWORD sslmode=disable'
primary_slot_name = 'standby_slot_1'
restore_command = ''

Если вы не используете слоты репликации — уберите primary_slot_name или создайте слот на primary. Для простого сценария можно начать без слота, но в реальном контуре лучше иметь контролируемую модель WAL retention.

Запустите standby:

pg_ctl -D ~/pgdata start

Проверки:

psql -d postgres -c "select pg_is_in_recovery();"

На standby вернёт t. На primary снова проверим:

psql -d postgres -c "select client_addr, state, sync_state from pg_stat_replication;"

Репликация с точки зрения практики: sync/async и ожидания

В простом локальном стенде обычно достаточно асинхронной репликации: мастер подтверждает транзакции сразу, а реплика догоняет WAL. Если хотите синхронизацию (synchronous replication), потребуется дополнительная настройка параметров на primary и standby, а также продуманная цена задержек. Для целей обучения и базовой отказоустойчивости лучше начать с асинхронной схемы и убедиться, что:

• standby стабильно подключён;
• не растёт очередь WAL за разумное время;
• при перезапусках оба узла поднимаются корректно.

Резервное копирование с pgBackRest

pgBackRest (pgBackRest) удобен тем, что даёт единый подход к бэкапам, инкрементам и хранению, включая сценарии с репликацией WAL. Ниже — общий план: настроить конфигурацию на машине, где будет исполняться pgBackRest, и обеспечить доступ к primary и/или standby.

Подготовка pgBackRest

Установите pgBackRest. В Termux может потребоваться отдельная сборка/установка в зависимости от доступности пакетов. В статье оставляем команду на уровне общего принципа.

pkg install -y pgbackrest

Если пакет недоступен в вашем окружении, используйте способ установки, соответствующий вашей сборке (например, скачивание релиза). Главное — чтобы бинарник pgbackrest исполнялся на том узле, где вы будете хранить конфигурацию.

Конфигурация pgBackRest

Предположим, что pgBackRest будет работать с primary. Создадим конфиг /etc/pgbackrest.conf или в домашней директории (вариант зависит от вашей среды). Используем домашний каталог:

mkdir -p ~/pgbackrest
nano ~/pgbackrest/pgbackrest.conf

Пример конфигурации (адаптируйте адреса, пользователи и пути):

[global]
repo1-path=/data/data/com.termux/files/home/pgbackrest/repo1
start-fast=y
process-max=4

[main]
pg1-path=/data/data/com.termux/files/home/pgdata
pg1-host=192.168.1.10
pg1-port=5432
pg1-user=postgres

# Если pgBackRest должен выполнять команды удалённо, настройте доступ по сети.
# Обычно нужен ssh; в рамках локальной сети это делается стандартными средствами.

Обратите внимание: пути repo1-path и pg1-path должны соответствовать реальной файловой структуре на узле, откуда pgBackRest читает/пишет. Вариант “всё на одном устройстве” и “распределённый” — разные по настройке путей.

Проверка конфигурации

pgbackrest --stanza=main check

Далее — полный бэкап:

pgbackrest --stanza=main backup

Если репликация WAL включена и вы планируете PITR (point-in-time recovery), настройте archiving/хранение WAL. В минимальном сценарии можно ограничиться base backup’ами, но для устойчивости часто важны и WAL.

Ротация и планирование

Для локального стенда можно запускать bэкапы вручную или по расписанию. В Termux удобно использовать termux-job-scheduler при наличии. Однако сама идея одинакова: регулярность, проверка целостности и логирование.

Пример проверки после бэкапа:

pgbackrest --stanza=main --type=diff info

Или запуск очередной команды проверки:

pgbackrest --stanza=main check

Горизонтальное масштабирование с pgpool-II

pgpool-II выступает как прокси/балансировщик: маршрутизирует запросы к master/replica, может выполнять роли failover (в зависимости от сценария), а также обрабатывает соединения приложений. В терминах локального стенда часто это “единая точка входа” для приложений: приложение подключается к pgpool-II, а тот уже распределяет/направляет запросы.

Развёртывание pgpool-II

Установка зависит от доступности пакета в Termux. Если pgpool-II доступен как пакет — установите. Если нет — учитывайте, что в Termux может потребоваться отдельная сборка/использование контейнера. В рамках статьи опишем настройку, предполагая доступность бинарников.

pkg install -y pgpool

Создадим конфигурационный файл. В Termux путь может отличаться, поэтому используйте тот, что принят в вашей сборке. Типовой конфиг — /etc/pgpool-II/pgpool.conf:

nano ~/pgpool.conf

Базовая конфигурация pgpool.conf

Концептуально нужно указать:

• Список backend’ов (primary и standby).
• Порт для слушания pgpool-II.
• Настройки health check.
• Режим маршрутизации (read/write split).

Пример (адаптируйте под вашу сеть):

# pgpool listen
listen_addresses = '0.0.0.0'
port = 9999

# Backend pool: 2 узла
backend_hostname0 = '192.168.1.10'
backend_port0 = 5432
backend_weight0 = 1

backend_hostname1 = '192.168.1.11'
backend_port1 = 5432
backend_weight1 = 1

# Указание, какие узлы являются primary/replica в рамках read/write split.
# В pgpool-II логика может зависеть от версии и параметров.

# Прокси-режим
enable_pool_hba = on
pool_passwd = 'pool_passwd'

# health check (примерно)
health_check_period = 10
health_check_timeout = 3

Создайте файл учётных данных для pgpool-II (pool_passwd). Например, администратор и пользователь, от имени которого pgpool будет делать проверки и проксировать соединения.

nano ~/pool_passwd

Смысл: pgpool-II должен иметь доступ к PostgreSQL backend’ам. Обычно создают отдельного пользователя в PostgreSQL с минимальными правами, и прописывают его в pool_passwd. Точные команды зависят от версии pgpool-II.

Запуск pgpool-II и проверка

Запуск:

pgpool -f ~/pgpool.conf -n

Проверим, что порт открыт с вашей рабочей машины в локальной сети (или с устройства, где тестируете приложение):

psql -h 192.168.1.20 -p 9999 -U app_user -d postgres -c "select now();"

Здесь 192.168.1.20 — адрес pgpool-II узла. Если подключения проходят — идём к проверке распределения запросов.

Read/Write split и практический тест

Для горизонтального масштабирования обычно стремятся:

• на запись направлять запросы только в primary;
• на чтение (SELECT) — направлять на replica(и) при корректной консистентности.

Тестовый сценарий: запустите несколько SELECT и посмотрите, к какому backend попали запросы (метрики/логирование pgpool, либо проверка статистики на backend).