Различия между режимами доступности для группы доступности Always On

2025-06-27

Область применения:SQL Server

В группах доступности AlwaysOn режим доступности — это свойство реплики, определяющее, может ли данная реплика доступности выполняться в режиме синхронной фиксации. Для каждой реплики доступности необходимо настроить режим на синхронную фиксацию, асинхронную фиксацию или на режим конфигурации.

Если первичная реплика настроена на асинхронный режим фиксации, она не ожидает, пока вторичная реплика запишет входящие записи журнала транзакций на диск (чтобы защитить журнал).

Если заданная вторичная реплика настроена на асинхронный режим фиксации, первичная реплика не ожидает, пока эта вторичная реплика зафиксирует журнал. Если и первичная, и вторичная реплика настроены на использование режима синхронной фиксации, то первичная реплика ожидает от вторичной реплики подтверждения фиксации журнала (за исключением случая, если вторичная реплика окажется неспособной проверить связь с первичной репликой в течение времени ожидания сеансапервичной реплики).

Примечание.

Если вторичная реплика с синхронной фиксацией превышает период ожидания сеанса для первичной реплики (по умолчанию — 10 секунд), первичная реплика временно помечает состояние синхронизации каждой базы данных на этой вторичной реплике как NOT SYNCHRONIZING и состояние самой реплики как NOT_HEALTHY. Когда вторичная реплика восстанавливает соединение с первичной репликой, они снова начинают работать в режиме синхронной фиксации.

Поддерживаемые режимы доступности

Группы доступности AlwaysOn поддерживают три режима доступности:

Режим асинхронной фиксации
Режим синхронной фиксации
Только режим конфигурации

Режим асинхронной фиксации представляет собой решение аварийного восстановления, которое работает хорошо тогда, когда реплики доступности распределены на значительном расстоянии. Если все вторичные реплики работают в асинхронном режиме фиксации, первичная реплика не ожидает, пока какая-либо из вторичных реплик зафиксирует журнал. Вместо этого сразу же после помещения записи журнала в локальный файл журнала первичная реплика отправляет клиенту подтверждение транзакции. Первичная реплика работает с минимальной задержкой при транзакциях в связи с тем, что вторичная реплика настроена на режим асинхронной фиксации.

Если текущий основной объект настроен для режима доступности асинхронной фиксации, он фиксирует транзакции асинхронно для всех вторичных реплик независимо от параметров отдельного режима доступности.

Дополнительные сведения см. подробнее в Asynchronous-Commit Режиме доступности в дальнейшем в этой статье.

Режим синхронной фиксации ставит высокий уровень доступности выше производительности, приводя к увеличению задержки транзакций. В режиме синхронной фиксации транзакции не отправляют клиенту подтверждение, пока вторичная реплика не зафиксирует журнал на диск. Когда в базе данных-получателе начинается синхронизация данных, вторичная реплика начинает применять записи журнала, поступающие от соответствующей базы данных-источника. Как только каждая запись журнала была затвердена, вторичная база данных входит в состояние SYNCHRONIZED. После этого каждая новая транзакция укрепляется вторичной репликой, прежде чем запись журнала поместится в локальный файл журнала. Когда все вторичные базы данных данной вторичной реплики синхронизированы, режим синхронной фиксации поддерживает ручное переключение на резервную базу данных и, при необходимости, автоматическое переключение.

Для получения дополнительной информации см. Synchronous-Commit Режим доступности, далее в этой статье.

Режим конфигурации применяется только к группам доступности, которые не входят в отказоустойчивый кластер Windows Server. Реплика в режиме конфигурации не содержит пользовательских данных. В режиме только конфигурации база данных реплики master сохраняет метаданные конфигурации группы доступности. Дополнительные сведения см. в разделе "Высокий уровень доступности" и "Защита данных" для конфигураций групп доступности.

На следующем рисунке показана группа доступности с пятью репликами доступности. Первичная реплика и одна вторичная реплика настроены на синхронный режим фиксации с автоматическим переключением. Одна из вторичных реплик настроена в режиме синхронной фиксации только с запланированным переключением вручную, а две вторичные реплики настроены в режиме асинхронной фиксации, который поддерживает только принудительное переключение вручную (чаще всего называется принудительное переключение).

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

Поведение синхронизации и аварийного переключения между двумя репликами доступности зависит от режима доступности каждой из них. Например, для синхронной фиксации необходимо настроить первичную реплику и вторичную реплику для синхронной фиксации. Аналогично, для автоматического переключения, обе реплики должны быть настроены на это. Таким образом, поведение ранее иллюстрированного сценария развертывания можно свести в следующей таблице, которая изучает поведение с каждой потенциальной первичной репликой:

Текущая первичная реплика	Целевые объекты автоматической отработки отказа	Поведение в режиме синхронного подтверждения с	Поведение режима асинхронной фиксации с помощью	Возможен автоматический резервный переход
01	02	02 и 03	04	Да
02	01	01 и 03	04	Да
03		01 и 02	04	Нет
04			01, 02 и 03	Нет

Как правило, узел 04 как реплика с асинхронной фиксацией развернут на сайте аварийного восстановления. Тот факт, что узлы 01, 02 и 03 остаются в режиме асинхронного подтверждения после переключения на узел 04, помогает предотвратить потенциальное снижение производительности в вашей группе доступности из-за высокой сетевой задержки между двумя сайтами.

Режим доступности асинхронной фиксации

В режиме асинхронной фиксациивторичная реплика никогда не бывает синхронизирована с первичной репликой. Хотя данная база данных-получатель может успевать за соответствующей базой данных-источником, любая другая база данных-получатель в любой момент может отставать. Режим асинхронной фиксации может быть полезен в сценарии аварийного восстановления, в котором первичная реплика и вторичная реплика разделены значительным расстоянием, и где небольшие ошибки не должны влиять на основную реплику, или в ситуациях, когда производительность более важна, чем синхронизированная защита данных. Кроме того, так как первичная реплика не ожидает подтверждения из вторичной реплики, проблемы во вторичной реплике никогда не влияют на первичную реплику.

Вторичная реплика с асинхронной фиксацией пытается синхронизироваться с получаемыми от первичной реплики записями журнала. Однако вторичные базы данных асинхронной фиксации всегда остаются несинхронизированными и могут немного отставать от соответствующих основных баз данных. Как правило, разница между вторичной базой данных с асинхронной фиксацией и основной базой данных незначительна. Однако этот разрыв может стать существенным, если сервер, содержащий вторичную реплику, перегружен или у сети низкая пропускная способность.

В режиме асинхронного подтверждения поддерживается только принудительное переключение на резерв (с возможной потерей данных). Принудительное переключение на резервную копию — это последняя мера, предназначенная только для ситуаций, когда текущая основная реплика остается недоступной длительное время, и немедленная доступность баз данных основной реплики более критична, чем риск возможной потери данных. Целевой объект отработки отказа должен быть репликой, роль которой находится в состоянии SECONDARY или RESOLVING. Цель резервирования переходит на первичную роль, и ее копии баз данных становятся основными базами данных. Все остальные базы данных-получатели и бывшая база данных-источник (как только она вновь становится доступной) приостанавливаются. Затем потребуется ручное возобновление работы каждой из них. В режиме асинхронной фиксации все журналы транзакций, которые исходная первичная реплика еще не отправлялась в предыдущую вторичную реплику, теряются. Это означает, что в некоторых или во всех новых базах данных-источниках могут отсутствовать транзакции, которые были зафиксированы недавно. Дополнительные сведения о том, как выполняется принудительная отработка отказа, и об оптимальных методах ее использования см. в статье Отработка отказа и режимы отработки отказа (группы доступности Always On).

Режим обеспечения доступности синхронного коммита

В режиме доступности синхронной фиксации (режим синхронной фиксации), после присоединения к группе доступности вторичная база данных синхронизируется с соответствующей основной базой данных и входит в SYNCHRONIZED состояние. Вторичная база данных остается SYNCHRONIZED до тех пор, пока синхронизация данных продолжается. Это гарантирует, что каждая транзакция, зафиксированная в данной базе данных-источнике, фиксируется в соответствующей базе данных-получателе. При синхронизации каждой вторичной базы данных на данной вторичной реплике состояние работоспособности синхронизации вторичной реплики в целом HEALTHY.

В этом разделе:

Факторы, которые нарушают синхронизацию данных
Как работает синхронизация на вторичной реплике
Режим синхронной фиксации только с ручным переключением при отказе
Режим синхронной фиксации с автоматическим переключением при отказе

Факторы, которые нарушают синхронизацию данных

После синхронизации всех баз данных вторичная реплика переходит в состояние HEALTHY. Синхронизированная вторичная реплика остается работоспособной, если не происходит одно из следующих действий:

Задержка или сбой в сети или компьютере приводит к истечении времени ожидания сеанса между вторичной репликой и первичной репликой.

Примечание.

Сведения о свойстве реплик доступности во время сеанса см. в разделе "Что такое группа доступности AlwaysOn?"
Вы приостанавливаете вторичную базу данных на вторичной реплике. Вторичная реплика перестаёт быть синхронизированной, и её состояние помечается как NOT_HEALTHY. Вторичная реплика не может снова стать работоспособной, пока приостановленная база данных-получатель не возобновляется и ресинхронизируется или не удаляется из группы доступности.
Вы добавляете основную базу данных в группу доступности. Ранее синхронизированные вторичные реплики вошли в NOT_HEALTHY состояние работоспособности синхронизации. Это состояние указывает, что по крайней NOT SYNCHRONIZING мере одна база данных находится в состоянии синхронизации. Данная вторичная реплика не может быть HEALTHY снова, пока соответствующая вторичная база данных не будет подготовлена на реплике, присоединена к группе доступности и синхронизирована с новой основной базой данных.
Вы изменяете для первичной или вторичной реплики режим доступности на асинхронную фиксацию. После изменения режима асинхронной фиксации вторичная реплика останется в HEALTHY состоянии работоспособности синхронизации, пока синхронизация данных продолжается. Однако если только первичная реплика изменяется на режим асинхронной фиксации, вторичная реплика с синхронной фиксацией перейдет в PARTIALLY_HEALTHY состояние синхронизации. Это состояние указывает, что хотя бы одна база данных находится в SYNCHRONIZING состоянии синхронизации, но ни одна из баз данных не находится в NOT SYNCHRONIZING состоянии.
Вы изменяете режим доступности любой вторичной реплики на режим с синхронной фиксацией. Это приводит к тому, что вторичная реплика будет помечена как в PARTIALLY_HEALTHY состоянии работоспособности синхронизации до тех пор, пока все базы данных не находятся в SYNCHRONIZED состоянии синхронизации.

Совет

Чтобы просмотреть работоспособность синхронизации группы доступности, реплики доступности или базы данных доступности, запросить synchronization_health или synchronization_health_desc столбец sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states или sys.dm_hadr_database_replica_states соответственно.

Как работает синхронизация на вторичной реплике

В режиме синхронной фиксации после того, как вторичная реплика присоединяется к группе доступности и устанавливает сеанс с первичной репликой:

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

После того как защищенный журнал на вторичной базе данных обновился до конца журнала на основной базе данных, состояние вторичной базы данных устанавливается в значение SYNCHRONIZED.

Время, необходимое для синхронизации, зависит от того, насколько далеко база данных-получатель стояла за базой данных-источником в начале сеанса. Эта разность измеряется по количеству записей журнала, первоначально полученных из первичной реплики, рабочей нагрузки в базе данных-источнике и скорости узла экземпляра вторичной реплики.

Процесс транзакции

В синхронном режиме фиксации транзакции фиксируются в обоих репликах в этом порядке:

Первичная реплика получает транзакцию от клиента.
Основная реплика записывает запись в журнал транзакций и одновременно отправляет запись журнала в вторичные реплики.

После записи в журнал транзакций основной базы данных, транзакция может быть отменена только в случае сбоя, если вторичная база данных не получила журнал.
Первичная реплика ожидает подтверждения от вторичной реплики синхронной фиксации.
Вторичная реплика фиксирует журнал и возвращает подтверждение первичной реплике.
Основная реплика завершает процесс фиксации и отправляет клиенту сообщение о подтверждении.

Тайм-аут синхронного подтверждения

Если вторичная реплика синхронной фиксации не подтверждает, что зафиксировала журнал, и время ожидания истекает, в группе доступности выполняются следующие действия:

Первичная реплика отмечает вторичную реплику как вышедшую из строя.
Состояние вторичной реплики изменяется на DISCONNECTED.
Основное останавливает ожидание подтверждения.
Группа доступности помечает состояние синхронизации как NOT SYNCHRONIZING, а состояние реплики как NOT_HEALTHY.

Такое поведение гарантирует, что вторичная реплика при сбое синхронной фиксации не препятствует жёсткому сохранению журналов на первичной реплике.

Когда вторичная реплика снова подключена к сети:

Состояние вторичной реплики изменяется на CONNECTED.
Вторичная реплика обрабатывает очередь отправки журнала первичной реплики.
Состояние синхронизации переходит в SYNCHRONIZING, а работоспособность реплики в PARTIALLY_HEALTHY.

После обработки очереди отправки журнала состояние синхронизации становится SYNCHRONIZED, а работоспособность реплики — HEALTHY.

Режим с синхронной фиксацией защищает данные за счет того, что требует их синхронизации между двумя экземплярами. Делается это за счет некоторого увеличения задержки транзакции.

Режим синхронной фиксации с только ручной отработкой отказа

Если между этими репликами установлено соединение и база данных синхронизирована, поддерживается ручное переключение. Если работа вторичной реплики нарушается, то это никак не сказывается на первичной реплике. Основная реплика работает без защиты, если отсутствуют SYNCHRONIZED реплики (то есть без отправки данных на какую-либо вторичную реплику). Если первичная реплика потеряна, вторичные реплики переходят в состояние RESOLVING, но владелец базы данных может принудительно выполнить переключение на вторичную реплику (с потенциальной потерей данных). Дополнительные сведения см. в разделе Отработка отказа и режимы отработки отказа (группы доступности Always On).

Режим синхронной фиксации с автоматическим переходом на резерв

Автоматический переход на другой ресурс обеспечивает высокий уровень доступности за счет того, что доступ к базам данных быстро восстанавливается после потери первичной реплики. Чтобы настроить группу доступности для автоматического переключения, необходимо установить для текущей первичной реплики и хотя бы одной вторичной реплики режим синхронной фиксации с автоматическим переключением. SQL Server 2019 (15.x) увеличил максимальное число синхронных реплик до 5, начиная с 3 в SQL Server 2017 (14.x). Вы можете настроить эту группу из пяти реплик для автоматического переключения в пределах группы. Существует одна первичная реплика, а также четыре синхронные вторичные реплики.

Кроме того, для того чтобы в заданный момент стало возможным автоматическое отказоустойчивое переключение, вторичная реплика должна быть синхронизирована с первичной репликой (это значит, что все вторичные базы данных синхронизированы), а кластер отказоустойчивости Windows Server (WSFC) должен иметь кворум. Если первичная реплика становится недоступной при этих условиях, происходит автоматическое переключение на резервную копию. Вторичная реплика переключается на роль первичной и предлагает свою базу данных как основную. Для получения дополнительной информации см. раздел "Автоматическое переключение" статьи "Режимы переключения и отказоустойчивости (группы доступности Always On).

Примечание.

Для получения информации о кворуме WSFC и группах доступности Always On, а также о режиме кворума и конфигурации голосования, см. Режимы кворума WSFC и конфигурация голосования (SQL Server).

Задержка данных на вторичной реплике

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

Основная реплика отправляет записи журнала изменений в основной базе данных на вторичные реплики. На каждой вторичной базе данных выделенный поток повтора применяет записи журнала. В базе данных-получателе доступа для чтения данное изменение данных не отображается в результатах запроса до тех пор, пока запись журнала, содержащая изменение, будет применена к базе данных-получателю, и транзакция была зафиксирована в базе данных-источнике.

Это означает, что между первичной и вторичной репликами обычно возникает некоторая задержка. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных. Для мониторинга приостановленного перемещения данных можно использовать панель мониторинга группы доступности AlwaysOn (SQL Server Management Studio) или динамическое представление управления sys.dm_hadr_database_replica_states.

Чтобы уменьшить задержку в предварительной версии SQL Server 2025 (17.x) и более поздних версиях, можно сократить время (в миллисекундах), необходимое основной реплике для фиксации транзакций в вторичную реплику. Дополнительные сведения см. в разделе "Конфигурация сервера: время фиксации группы доступности (мс)".

Чтобы изменить режим доступности и режим отработки отказа

Настройка голосов кворума

Отработки отказа вручную

Просмотр состояний групп доступности, реплик доступности и баз данных