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

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

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

Физическая потоковая репликация и слоты репликации в PostgreSQL

Обновлено: 26.08.2026  ·  Официальная база знаний
  • Реплика переходит в статус disconnected и перестает получать обновления с Master.
  • В логах Standby фиксируется ошибка: could not receive data from WAL stream: FATAL: requested WAL segment has already been removed.
  • На основном сервере накапливаются гигабайты WAL из-за зависшего или отключенного слота репликации.

1. Настройка Master-сервера (Primary)

В postgresql.conf:

wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
wal_keep_size = 4096MB # Резервный буфер WAL для реплик

В pg_hba.conf разрешите доступ пользователю репликации:

host replication replicator 192.168.1.50/32 scram-sha-256

2. Создание физического слота репликации на Primary

SELECT pg_create_physical_replication_slot('standby_node1');

3. Инициализация Standby-сервера через pg_basebackup

# На реплике: очистить каталог данных и стянуть копию с мастера
pg_basebackup -h 192.168.1.10 -p 5432 -U replicator -D /var/lib/postgresql/16/main/ -Fp -Xs -R -S standby_node1 -v

Флаг -R автоматически создаст файл standby.signal и пропишет строку подключения primary_conninfo.

4. Мониторинг отставания репликации (Replication Lag) на Primary

SELECT 
    client_addr,
    application_name,
    state,
    sync_state,
    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;

5. Очистка неиспользуемых слотов при авариях

-- Просмотр активных слотов и удерживаемых WAL
SELECT slot_name, active, wal_status FROM pg_replication_slots;

-- Удаление мертвого слота, блокирующего удаление WAL на Primary
SELECT pg_drop_replication_slot('abandoned_standby');
Практический опыт инженера: Для баз 1С:Предприятие используйте только асинхронную репликацию с отдельным Standby для тяжелых аналитических отчетов. Синхронная репликация при малейших сетевых задержках между серверами резко увеличит время проведения документов в 1С.

Частые вопросы (FAQ)

Зачем нужны физические слоты репликации (Replication Slots)?

Слот гарантирует, что Primary сервер не удалит и не перезапишет ни один сегмент WAL, пока он не будет гарантированно получен и подтвержден репликой, предотвращая рассинхронизацию.

Чем опасен неактивный слот репликации при падении Standby сервера?

Если реплика отключилась, слот остается в базе и удерживает все входящие WAL-файлы. На Primary сервере быстро закончится свободное место на диске, что приведет к остановке всей СУБД.

Как ограничить максимальный объем WAL, который может удержать слот?

Используйте параметр max_slot_wal_keep_size (например, 32GB). Если отставание реплики превысит этот лимит, слот будет инвалидирован, сохранив работоспособность Primary.

В чем разница между асинхронной и синхронной репликацией?

При асинхронной репликации Master подтверждает транзакцию клиенту сразу после локальной записи. При синхронной (synchronous_commit = on) Master ожидает подтверждения записи WAL хотя бы на одной реплике.