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

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

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

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

Настройка автоматического перехода (Automatic Failover) в AlwaysOn

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

Сбои механизмов автоматического переключения ролей в кластере AlwaysOn:

  • Сервер падает или теряет связь, но автоматический переход на вторичную реплику не происходит (Downtime сервиса);
  • Ложные переключения (False Failover) при кратковременных скачках нагрузки на процессор;
  • Рассинхронизация ролей и переход группы в состояние изолированного сбоя (Split-Brain).

1. Обязательные условия для автоматического перехода (Automatic Failover)

  • Режим доступности: Synchronous Commit на обеих нодах;
  • Режим перехода: Automatic;
  • Кластер WSFC имеет стабильный кворум (Witness: Node, Disk или Cloud Witness).
ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE1' WITH (FAILOVER_MODE = AUTOMATIC);

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

ALTER AVAILABILITY GROUP [AG_1C] 
MODIFY REPLICA ON N'SQL-NODE2' WITH (FAILOVER_MODE = AUTOMATIC);
GO

2. Тонкая настройка порогов чувствительности сбоя

Управление условиями переключения через FAILURE_CONDITION_LEVEL (от 1 до 5):

ALTER AVAILABILITY GROUP [AG_1C] 
SET (FAILURE_CONDITION_LEVEL = 3);

-- Увеличение таймаута проверки здоровья до 60 секунд (защита от ложных сработок)
ALTER AVAILABILITY GROUP [AG_1C] 
SET (HEALTH_CHECK_TIMEOUT = 60000);
GO

Уровни Failure Condition:

  • Уровень 1: Сервер упал (служба SQL остановлена);
  • Уровень 2: Сервер не отвечает (внутренние зависания);
  • Уровень 3 (По умолчанию): Критические системные ошибки ядра (Internal Error, Spinlock deadlocks);
  • Уровень 4: Исчерпание пула памяти (Resource exhaustion);
  • Уровень 5: Любые внутренние ошибки потоков (Aggressive).

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

-- Выполняется на целевой вторичной реплике для планового переключения:
ALTER AVAILABILITY GROUP [AG_1C] FAILOVER;
GO
💡 Практика специалистов: Не ставьте HEALTH_CHECK_TIMEOUT ниже 30000 мс в высоконагруженных средах 1С: генерация тяжелых отчетов или скачки памяти могут спровоцировать ложный сброс кворума кластера.

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

Что произойдет, если связь между узлами разорвется в синхронном режиме?

Если кворум WSFC сохранен, первичная реплика перейдет в асинхронный режим, позволяя пользователям продолжать работу. Вторичная реплика перейдет в статус 'Not Synchronizing', предотвращая Split-Brain.

Почему уровень 5 (Failure Condition Level 5) опасен в production?

Уровень 5 реагирует на мелкие временные ошибки пользовательских процессов, что может вызвать бесконечные циклические переключения ролей между узлами под нагрузкой.

Какая конфигурация свидетеля кворума оптимальна для двухнодового AlwaysOn?

Для двух нод в одном датацентре оптимален File Share Witness (общая папка на третьем независимом сервере), либо Cloud Witness в облаке Azure/Yandex Cloud.

Теряются ли активные пользовательские транзакции при автоматическом Failover?

Зафиксированные транзакции (Committed) гарантированно сохраняются. Незафиксированные в момент падения транзакции откатываются (Rollback) на новом узле.

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