Синхронная и асинхронная репликация PostgreSQL: synchronous_commit и Streaming
- Зависание клиентских транзакций (COMMIT) при временной сетевой недоступности синхронной реплики.
- Потеря части подтвержденных транзакций (RPO > 0) при аварийном переключении на асинхронную реплику.
- Отставание потоковой репликации (WAL replication lag) и накопление слотов репликации на мастере.
1. Настройка мастера (Primary) в postgresql.conf
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 4096MB
# Режимы синхронизации (off, local, remote_write, on, remote_apply)
synchronous_commit = on
# Кворумная синхронная репликация (1 подтверждение из 2 нод)
synchronous_standby_names = 'ANY 1 (node_replica_1, node_replica_2)'2. Создание слота репликации на мастере
SELECT * FROM pg_create_physical_replication_slot('standby_1_slot');3. Инициализация реплики через pg_basebackup
# Остановка сервиса на реплике
systemctl stop postgresql
rm -rf /var/lib/postgresql/16/main/*
# Снятие физической копии с мастера
pg_basebackup -h 192.168.10.50 -U replicator -p 5432 \
-D /var/lib/postgresql/16/main -Fp -Xs -R \
--slot=standby_1_slot4. Конфигурация параметров реплики (postgresql.auto.conf)
Укажите уникальное имя ноды, соответствующее значению в synchronous_standby_names:
primary_conninfo = 'host=192.168.10.50 port=5432 user=replicator password=Secret application_name=node_replica_1'
primary_slot_name = 'standby_1_slot'
hot_standby = onsystemctl start postgresql5. Проверка статуса репликации на Primary
SELECT
application_name,
client_addr,
state,
sync_state,
sync_priority,
pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn) AS write_lag_bytes,
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication; Частые вопросы (FAQ)
В чем разница между synchronous_commit = remote_write и remote_apply?
remote_write ожидает, пока реплика запишет WAL в буферы ОС (гарантия от падения СУБД, но не ОС). remote_apply ожидает фактического применения WAL в базу данных реплики, гарантируя немедленную консистентность чтения на standby.
Что произойдет с мастером при synchronous_commit = on, если единственная синхронная реплика упадет?
Мастер продолжит принимать операции чтения, но все транзакции, выполняющие запись (INSERT, UPDATE, DELETE), зависнут на этапе завершения COMMIT в ожидании подтверждения от упавшей реплики.
Чем опасны неактивные слоты репликации (replication slots)?
Если реплика отключилась, мастер продолжит бесконечно сохранять все новые файлы WAL на диске, чтобы реплика не потеряла позицию, что может привести к 100% заполнению диска и падению мастера.
Как быстро перевести реплику в режим мастера при аварии?
Выполните команду на стороне реплики: pg_ctl promote -D /var/lib/postgresql/16/main или через SQL: SELECT pg_promote();.