Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

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

REPLICATION_SYNC_LAG 1С:Предприятие и СУБД

Синхронная и асинхронная репликация 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();.

Полезные материалы
Рекомендуем