Режимы доступности (группы доступности AlwaysOn)

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

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

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

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

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

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

• Связанные задачи

• См. также

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

Группы доступности AlwaysOn поддерживает два режима доступности — режим асинхронной фиксации и режим синхронной фиксации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Режим синхронной фиксации только с переходом на другой ресурс вручную

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

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

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

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

  Примечание
  Сведения о свойстве ожидания сеанса для реплик доступности см. в разделе Обзор групп доступности AlwaysOn (SQL Server).

• Пользователь приостанавливает базу данных-получатель на вторичной реплике. Вторичная реплика теряет синхронизацию и переходит в состояние работоспособности синхронизации 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. Время, необходимое для выполнения синхронизации, зависит главным образом от того, насколько база данных-получатель отстала от базы данных-источника в начале сеанса (отставание измеряется числом записей журнала, первоначально полученных от первичной реплики), от рабочей нагрузки на базу данных-источник и от быстродействия компьютера, на котором находится экземпляр сервера, где размещена вторичная реплика.

Синхронность операции достигается следующим образом.

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

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

3. Вторичная реплика фиксирует журнал на диск и возвращает подтверждение первичной реплике.

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

   Примечание

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

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

Режим синхронной фиксации только с переходом на другой ресурс вручную

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

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

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

Кроме того, для автоматического перехода на другой ресурс в заданный момент вторичная реплика должна быть синхронизирована с первичной репликой (это значит, что все базы данных-получатели синхронизированы), а кластер WSFC должен иметь кворум. Если первичная реплика становится недоступной при описанных выше условиях, происходит автоматический переход на другой ресурс. Вторичная реплика переключается в роль первичной и предлагает свои базы данных как базы данных-источники. Дополнительные сведения см. в подразделе «Автоматический переход на другой ресурс» раздела Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).

Примечание
Сведения о кворуме WSFC и Группы доступности AlwaysOn см. в разделе Режим кворума и участвующая в голосовании конфигурация WSFC (SQL Server).

[В начало]

Связанные задачи

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

• Смена режима доступности для реплики доступности (SQL Server)

• Изменение режима отработки отказа для реплики доступности (SQL Server)

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

• Просмотр параметров NodeWeight кворума кластера

• Настройка параметров NodeWeight кворума кластера

• Принудительный запуск кластера WSFC без кворума

Выполнение перехода на другой ресурс вручную

• Выполнение запланированного перехода на другой ресурс вручную для группы доступности (SQL Server)

• Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server)

• Использование мастера отработки отказа группы доступности (Среда SQL Server Management Studio)

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

• sys.dm_hadr_availability_group_states (Transact-SQL)

• sys.dm_hadr_availability_replica_states (Transact-SQL)

• sys.dm_hadr_database_replica_states (Transact-SQL)

[В начало]

См. также

• Руководство по решениям режима AlwaysOn в Microsoft SQL Server для обеспечения высокой доступности и аварийного восстановления

• Блог группы разработчиков SQL Server AlwaysOn: официальный блог группы разработчиков SQL Server AlwaysOn

[В начало]

См. также

Основные понятия

Обзор групп доступности AlwaysOn (SQL Server)

Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn)

Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server