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

MSSQL Error 35279: Connection between primary and secondary terminating timeout — Решение

Обновлено: 25.08.2026 · Официальная документация ↗

Запись в Errorlog: The connection between the primary and secondary replica is terminating because of a timeout. Availability Group ID: '...'.
Периодические кратковременные разрывы репликации баз 1С с последующим автовосстановлением.
В журнале Windows фиксируются сетевые задержки или потери пакетов (Packet Loss).

1. Проверка и увеличение параметра Session Timeout

По умолчанию таймаут сессии между репликами составляет 10 секунд. При высоких пиковых нагрузках в 1С увеличьте его до 15–20 секунд:

-- Увеличение Session Timeout для обеих реплик Always On
ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE-01' 
WITH (SESSION_TIMEOUT = 20);

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE-02' 
WITH (SESSION_TIMEOUT = 20);

2. Диагностика качества сетевого канала между серверами СУБД

# Непрерывный пинг пакетами большого размера для выявления потерь и фрагментации
Test-Connection -ComputerName "SQL-NODE-02" -Count 100 -BufferSize 1400

3. Мониторинг ожиданий HADR_SYNC_COMMIT

SELECT 
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'HADR_SYNC_COMMIT';

4. Настройка сетевой очереди и буферов (Receive/Transmit Buffers)

В свойствах физического сетевого адаптера на обоих серверах увеличьте Receive Buffers (Rx) и Transmit Buffers (Tx) со стандартных 256/512 до максимальных 2048/4096 дескрипторов.

💡 Практика специалистов: Если репликация Always On для 1С настроена между гео-распределенными ЦОД (Cross-Site), минимально допустимый SESSION_TIMEOUT составляет 20–30 секунд с обязательной настройкой резервного L2/L3 канала.

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

Что означает параметр SESSION_TIMEOUT в Always On?

Это максимальное время в секундах, в течение которого реплика ожидает ping-сообщения (heartbeat) от другой реплики перед тем, как признать соединение разорванным по таймауту.

Почему не стоит ставить SESSION_TIMEOUT слишком большим (например, 60 секунд)?

Слишком большой таймаут затягивает обнаружение реального падения основной реплики, увеличивая время простоя (Downtime) базы 1С до момента переключения.

Влияет ли высокая нагрузка на диск на ошибку 35279?

Да, если поток записи в log pool вторичной реплики блокируется из-за задержек диска, сетевой стек эндпоинта может перестать своевременно отвечать на heartbeat.

Как сбросить накопившуюся статистику ожиданий HADR?

Выполните команду: DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);