Как переключить master?

Приведены пошаговые инструкции для ручного failover и автоматизированного переключения с использованием repmgr. Пример подтвержден на стенде 2025-11-12. 4.1. Ручной failover (примордиальный сценарий) Проверка состояния реплик: SELECT application_name, client_addr, state, sync_state FROM pg_stat_replication; -- выберите наиболее актуальную реплику с минимальным lag Остановите запись на старом мастере (если он доступен): остановите приложение или заблокируйте запись через прокси. Это важно, чтобы не допустить split-brain. На выбранной реплике выполните promote: sudo -u postgres pg_ctl -D /var/lib/pgsql/14/data promote -- или sudo systemctl start postgresql-14 && sudo -u postgres touch /var/lib/pgsql/14/data/trigger_file && sudo systemctl reload postgresql-14 Команда работает быстро: promote обычно занимает 1–3 секунды плюс replay WAL. Обновите DNS/VIP: переместите floating IP с 10.0.0.10 -> 10.0.0.11 или переключите балансировщик. TTL для DNS лучше держать 30–60 секунд заранее....

как правильно выбрать между logical и streaming?

Выбор зависит от задачи: если нужно точное поблочное копирование и быстрый failover — streaming (физическая репликация). Если требуется реплицировать только часть таблиц, миграция между версиями PostgreSQL или репликация между разными схемами — logical. Logical требует wals_level = logical и использует репликационные слоты, которые удерживают WAL. Для гибридных конфигураций часто ставят wals_level = logical и настраивают и физические, и логические механизмы одновременно.

сколько реплик ставить для HA?

Минимум 2 реплики рекомендуется для обеспечения отказоустойчивости: одна синхронная (synchronous_standby_names = '1 (replica1)') и одна асинхронная для географического распределения. Для SLA 99.95% обычно используют 2–3 реплики в разных AZ/дата-центрах. Если нужен компактный RPO < 1 с, ставьте как минимум одну синхронную реплику и используйте быстрые сети 10Gbps и SSD NVMe.

зачем нужны replication slots и как контролировать их размер?

Replication slots предотвращают удаление WAL, пока реплика не прочитала данные. Физические слоты — для streaming, логические — для logical replication. Мониторьте их размер запросом к pg_replication_slots и ограничивайте количество слотов (например, max_replication_slots = 10). Если слот неактивен более 24 часов и удерживает WAL > 10GB, планируйте принудительное удаление после анализа: SELECT pg_drop_replication_slot('slotname');. Для логических подписок контролируйте долгие initial copy и при необходимости используйте copy_data = false.

чем полезен pg_rewind и когда его использовать?

pg_rewind синхронизирует старый мастер (который еще содержит write-паттерны, несовместимые с новым мастером) с текущим мастером без полного резервного копирования. Используется после failover, когда старый мастер может быть «отставшим» и требует отката к точке, где начался новый мастер. pg_rewind эффективен для крупных баз: сокращает время восстановления с часов до десятков минут, если divergence небольшое. Перед применением убедитесь, что new master сохраняет историю WAL, доступную для rewind.

сколько места нужно для WAL и как резервировать?

Планируйте WAL-архивирование исходя из транзакционной активности. Для среднего OLTP с 100 GB данных в день можно рассчитывать на 1–4 GB WAL в час; для высокой нагрузки — 10–20 GB/час. Настройте max_wal_size (например, 4–8GB) и wal_keep_size (например, 1024MB–4096MB) и храните архивы на отдельном диске или S3 с ретеншеном 7–30 дней. Проверяйте использование диска по cron и alert'ам при достижении 70% заполнения.

Репликация PostgreSQL: streaming + logical

Q: зачем нужны replication slots и как контролировать их размер?

Replication slots предотвращают удаление WAL, пока реплика не прочитала данные. Физические слоты — для streaming, логические — для logical replication. Мониторьте их размер запросом к pg_replication_slots и ограничивайте количество слотов (например, max_replication_slots = 10). Если слот неактивен более 24 часов и удерживает WAL > 10GB, планируйте принудительное удаление после анализа: SELECT pg_drop_replication_slot('slotname');. Для логических подписок контролируйте долгие initial copy и при необходимости используйте copy_data = false.

Репликация PostgreSQL: streaming + logical | KtoHto

В postgresql.conf (обычно /var/lib/pgsql/14/data/postgresql.conf) задайте параметры:
```
listen_addresses = '*'
wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 1024MB
max_wal_size = 4GB
checkpoint_timeout = 5min
archive_mode = on
archive_command = 'test ! -f /var/lib/pgsql/wal_archive/%f && cp %p /var/lib/pgsql/wal_archive/%f'
```
Здесь wal_level = logical подходит и для физической репликации; если нужен только физический — можно установить replica, но для гибридных сценариев устанавливайте logical.
В pg_hba.conf добавьте строку для репликации:
```
host replication replicator 10.0.0.11/32 md5
```
Стоимость: создайте пароль пользователя replicator с сильной строкой не менее 16 символов.
Перезапустите сервер:
```
sudo systemctl reload postgresql-14
```
или sudo pg_ctlcluster 14 main reload на Debian/Ubuntu.

psql -U postgres -c "CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'S0m3$tr0ngP@ssw0rd'"

sudo systemctl stop postgresql-14
sudo -u postgres rm -rf /var/lib/pgsql/14/data/*
sudo -u postgres pg_basebackup -h 10.0.0.10 -D /var/lib/pgsql/14/data -U replicator -P -X stream --wal-method=stream

primary_conninfo = 'host=10.0.0.10 port=5432 user=replicator password=S0m3$tr0ngP@ssw0rd application_name=standby1'
primary_slot_name = 'standby1_slot'
hot_standby = on

SELECT slot_name, plugin, slot_type, active FROM pg_replication_slots;
SELECT pid, state, application_name, client_addr FROM pg_stat_replication;

CREATE ROLE analytics LOGIN PASSWORD 'Analyt1cs$' NOSUPERUSER;
GRANT CONNECT ON DATABASE mydb TO analytics;
GRANT USAGE ON SCHEMA public TO analytics;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO analytics;

SELECT application_name, client_addr, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS byte_lag
FROM pg_stat_replication;

-- На реплике
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;

wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

-- На master
psql -U postgres -d mydb -c "CREATE PUBLICATION pub_all FOR ALL TABLES;"
-- или частичный набор
psql -U postgres -d mydb -c "CREATE PUBLICATION pub_orders FOR TABLE orders, order_items;"

-- На standby, но не в режиме hot standby как физическая репликация; обычно логическая репликация ставится на отдельный узел
psql -U postgres -d mydb -c "CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.0.0.10 port=5432 user=replicator password=S0m3$tr0ngP@ssw0rd dbname=mydb' PUBLICATION pub_all;
"

SELECT slot_name, plugin, active, pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), restart_lsn)) as retained
FROM pg_replication_slots WHERE slot_type='logical';

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

SELECT application_name, client_addr, state, sync_state FROM pg_stat_replication;
-- выберите наиболее актуальную реплику с минимальным lag

Остановите запись на старом мастере (если он доступен): остановите приложение или заблокируйте запись через прокси. Это важно, чтобы не допустить split-brain.

На выбранной реплике выполните promote:

sudo -u postgres pg_ctl -D /var/lib/pgsql/14/data promote
-- или
sudo systemctl start postgresql-14 && sudo -u postgres touch /var/lib/pgsql/14/data/trigger_file && sudo systemctl reload postgresql-14

Команда работает быстро: promote обычно занимает 1–3 секунды плюс replay WAL.

Обновите DNS/VIP: переместите floating IP с 10.0.0.10 -> 10.0.0.11 или переключите балансировщик. TTL для DNS лучше держать 30–60 секунд заранее.
Переподключите приложения к новому мастеру и включите запись. Для минимизации времени простоя заранее подготовьте healthcheck и скрипт переключения.

-- На каждом узле /etc/repmgr/14/repmgr.conf
cluster=repl_cluster
node_id=2
node_name='standby1'
host='10.0.0.11'
conninfo='host=10.0.0.11 user=repmgr dbname=repmgr'
priority=100
promote_command='repmgr standby promote'
follow_command='repmgr standby follow --log-level-console INFO'

Обнаружьте наличие двух мастеров: проверьте, какие узлы принимают записи, через monitoring и приложение. Логи Postgres покажут подтверждения записи и различия timeline.

На каждом мастере выполните:

SELECT pg_current_wal_lsn(), pg_walfile_name(pg_current_wal_lsn()) AS current_walfile, pg_is_in_recovery();
SELECT timeline_id FROM pg_control_checkpoint(); -- или просмотр истории timeline

Определите, какие данные уникальны для каждой ветки: выполните контрольные суммы таблиц или SELECT COUNT и сравните по ключевым таблицам.

# На A (новый мастер) должен быть доступен
-- убедитесь, что на A включено логирование и есть подключение

# На B остановите PostgreSQL
sudo systemctl stop postgresql-14

# На B очистите конфиг, сохраните postgresql.conf
sudo -u postgres pg_rewind --target-pgdata=/var/lib/pgsql/14/data --source-server='host=10.0.0.10 user=repl_user port=5432' --progress

# После завершения запустите B как реплику
sudo -u postgres touch /var/lib/pgsql/14/data/standby.signal
# добавьте primary_conninfo в postgresql.auto.conf
sudo systemctl start postgresql-14

Репликация PostgreSQL: streaming + logical

Комментарии (0)

Типы репликации PG

Шаг 1: streaming replication

1.1. Подготовка master

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

1.3. Создание физической реплики через pg_basebackup

1.4. Подключение реплики

1.5. Проверка состояния

Шаг 2: hot standby

2.1. Параметры для низкой латентности чтения

2.2. Настройка read-only пользователей

2.3. Мониторинг задержки репликации

Шаг 3: logical replication

3.1. Настройки на master

3.2. Создание публикации

3.3. Создание подписки на реплике

3.4. Управление слотами и очистка

3.5. Сценарии использования logical

Как переключить master?

4.1. Ручной failover (примордиальный сценарий)

4.2. Автоматический failover с repmgr (пример конфигурации)

4.3. Проверка после переключения

Что делать при split brain?

5.1. Быстрая диагностика

5.2. Выбор основной ветки

5.3. Использование pg_rewind для синхронизации старого мастера

5.4. Что делать при сильном расхождении

5.5. Предотвращение split brain

Частые вопросы

как правильно выбрать между logical и streaming?

сколько реплик ставить для HA?

зачем нужны replication slots и как контролировать их размер?

чем полезен pg_rewind и когда его использовать?

сколько места нужно для WAL и как резервировать?