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

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

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

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

MSSQL Error 35262: Availability group is not ready for automatic failover — Решение

Обновлено: 25.08.2026 · Официальная документация ↗
  • Предупреждение в Errorlog: Availability group 'AG_1C' is not ready for automatic failover. The secondary replica is not synchronized.
  • При падении основного узла автоматический переход на резервный сервер не происходит, база 1С простаивает.
  • Параметр synchronization_state вторичной реплики отображается как SYNCHRONIZING вместо SYNCHRONIZED.

1. Проверка готовности реплик к автоматическому Failover

-- Проверка статуса готовности реплик Always On
SELECT 
    ag.name AS ag_name,
    ar.replica_server_name,
    ar.availability_mode_desc,
    ar.failover_mode_desc,
    drs.is_failover_ready,
    drs.synchronization_state_desc,
    drs.log_send_queue_size
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag ON ar.group_id = ag.group_id;

2. Проверка режима доступности и условий автоматического перехода

Для корректного автоматического Failover реплики должны находиться в режиме SYNCHRONOUS_COMMIT и AUTOMATIC failover:

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE-01' 
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC);

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE-02' 
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC);

3. Анализ очереди отправки журнала (Log Send Queue)

Если очередь log_send_queue_size растет при интенсивной записи в 1С (например, проведение документов или пакетный импорт), реплика теряет статус SYNCHRONIZED:

SELECT 
    database_name,
    log_send_queue_size,
    log_send_rate,
    (log_send_queue_size / NULLIF(log_send_rate, 0)) AS est_send_seconds
FROM sys.dm_hadr_database_replica_states
WHERE is_local = 0;

4. Оптимизация сетевого адаптера репликации

Увеличьте пропускную способность сети синхронизации и включите Jumbo Frames (9000 MTU) на интерфейсах, выделенных под Always On Endpoint.

💡 Практика специалистов: Для высоконагруженных баз 1С размещайте журнал транзакций (ldf) вторичной реплики на накопителях NVMe корпоративного класса с высоким ресурсом записи (DWPD >= 3), иначе Secondary будет регулярно отставать.

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

Почему реплика переходит из состояния SYNCHRONIZED в SYNCHRONIZING?

Это происходит, когда скорость генерации записей журнала транзакций на Primary (при массовых операциях в 1С) превышает пропускную способность сети или скорость записи LDF на Secondary.

Произойдет ли автоматический Failover, если флаг is_failover_ready равен 0?

Нет, кластер WSFC намеренно заблокирует автоматический переход, чтобы предотвратить потерю данных (Data Loss).

Можно ли выполнить ручной переход при ошибке 35262?

Ручной плановый переход без потери данных невозможен. Возможен только принудительный аварийный переход с потерей данных (FORCE_FAILOVER_ALLOW_DATA_LOSS).

Влияет ли сжатие журнала Always On на скорость синхронизации?

Начиная с SQL Server 2014 сжатие транспортного потока Always On включено по умолчанию. На процессорах без аппаратного ускорения это может увеличивать задержки отправки.

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