Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.

Синхронная и асинхронная репликация PostgreSQL: synchronous_commit и Streaming

Обновлено: 26.08.2026  ·  Официальная база знаний
  • Зависание клиентских транзакций (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_slot

4. Конфигурация параметров реплики (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 = on
systemctl start postgresql

5. Проверка статуса репликации на 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;
Практический опыт инженера: Для защиты от блокировки записи при авариях используйте кворумную синхронизацию (ANY 1 (...) из двух синхронных реплик) или настройте автоматический фейловер с помощью Patroni + etcd.

Частые вопросы (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();.