Различия между режимами доступности для группы доступности Always On
Область применения: 
SQL Server
В группах доступности AlwaysOn режим доступности — это свойство реплики, определяющее, может ли данная реплика доступности выполняться в режиме синхронной фиксации. Для каждой реплики доступности режим доступности необходимо настроить на режим синхронной или асинхронной фиксации либо только на режим конфигурации. Если первичная реплика настроена на режим асинхронной фиксации, она не ждет, что какая-либо вторичная реплика зафиксирует входящие записи журнала транзакций на диск (для фиксации журнала). Если данная вторичная реплика доступности настроена на режим асинхронной фиксации, первичная реплика не ждет, что эта вторичная реплика зафиксирует журнал. Если и первичная, и вторичная реплика настроены на использование режима синхронной фиксации, то первичная реплика ожидает от вторичной реплики подтверждения фиксации журнала (за исключением случая, если вторичная реплика окажется неспособной проверить связь с первичной репликой в течение времени ожидания сеансапервичной реплики).
Примечание.
Если вторичная реплика превышает время ожидания сеанса первичной реплики, то последняя реплика временно переходит в режим асинхронной фиксации по отношению к этой вторичной реплике. Когда вторичная реплика восстанавливает соединение с первичной репликой, они снова начинают работать в режиме синхронной фиксации.
Поддерживаемые режимы доступности
Группы доступности AlwaysOn поддерживают три режима доступности— асинхронный режим фиксации, режим синхронной фиксации и только режим конфигурации, как показано ниже.
Режим асинхронной фиксации представляет собой решение аварийного восстановления, которое работает хорошо тогда, когда реплики доступности распределены на значительном расстоянии. Если каждая вторичная реплика доступности работает в режиме асинхронной фиксации, первичная реплика не ждет, пока какая-либо вторичная реплика зафиксирует журнал. Вместо этого сразу же после помещения записи журнала в локальный файл журнала первичная реплика отправляет клиенту подтверждение транзакции. Первичная реплика работает с минимальной задержкой транзакции в отношении вторичной реплики, настроенной для работы в режиме асинхронной фиксации. Если текущая первичная реплика настроена на работу в режиме асинхронной фиксации, то она фиксирует транзакции асинхронно для всех вторичных реплик, независимо от режимов доступности, заданных в каждой из них.
Дополнительные сведения см. далее в подразделе Режим доступности с асинхронной фиксациейдалее в этом разделе.
Режим синхронной фиксации отдает предпочтение высокому уровню доступности и защите данных перед производительностью ценой повышенной задержки транзакций. В режиме синхронной фиксации транзакции не отправляют клиенту подтверждение, пока вторичная реплика не зафиксирует журнал на диск. Когда в базе данных-получателе начинается синхронизация данных, вторичная реплика начинает применять записи журнала, поступающие от соответствующей базы данных-источника. Сразу после того, как все записи журнала зафиксированы на диск, база данных-получатель переходит в состояние SYNCHRONIZED. После этого каждая новая транзакция фиксируется вторичной репликой перед помещением записи журнала в локальный файл журнала. Когда все базы данных-получатели данной вторичной реплики синхронизированы, режим синхронной фиксации поддерживает переход на другой ресурс вручную, а также автоматический переход на другой ресурс.
Дополнительные сведения см. далее в подразделе Режим доступности с синхронной фиксациейдалее в этом разделе.
Режим только конфигурации применяется к группам доступности, которые не находятся на отказоустойчивом кластере Windows Server. Реплика в режиме только конфигурации не содержит данных пользователя. В этом режиме реплика базы данных master хранит метаданные конфигурации группы доступности. Дополнительные сведения см. в разделе Группа доступности с репликой только для конфигурации.
На следующем рисунке показана группа доступности с пятью репликами доступности. Первичная реплика и одна вторичная реплика настроены в режиме синхронной фиксации с автоматическим переходом на другой ресурс. Другая вторичная реплика настроена для синхронной фиксации только с запланированным переходом на другой ресурс вручную, а две вторичные реплики настроены в режиме асинхронной фиксации, который поддерживает только принудительный переход на другой ресурс вручную (обычно называется принудительной отработкой отказа).
Синхронизация и отработка отказа между двумя репликами доступности зависит от режима доступности обеих реплик. Например, для синхронной фиксации должны быть настроены обе рассматриваемые реплики: и текущая первичная, и вторичная. Аналогично обе реплики должны быть настроены для автоматического перехода на другой ресурс. Таким образом, сводку поведения для проиллюстрированного сценария развертывания можно показать в следующей таблице, которая анализирует поведение с каждой потенциальной первичной репликой.
| Текущая первичная реплика | Целевые объекты автоматического перехода на другой ресурс | Режим синхронной фиксации с режимом | Режим асинхронной фиксации с режимом | Автоматическая отработка отказа возможна |
|---|---|---|---|---|
| 01 | 02 | 02 и 03 | 04 | Да |
| 02 | 01 | 01 и 03 | 04 | Да |
| 03 | 01 и 02 | 04 | No | |
| 04 | 01, 02 и 03 | No |
Как правило, узел 04 как реплика с асинхронной фиксацией развернут на сайте аварийного восстановления. Тот факт, что узлы 01, 02 и 03 остаются в режиме асинхронной фиксации после перехода на узел 04, помогает предотвратить потенциальное снижение производительности в группе доступности из-за большой задержки в сети между двумя сайтами.
Asynchronous-Commit Availability Mode
В режиме асинхронной фиксациивторичная реплика никогда не бывает синхронизирована с первичной репликой. Хотя данная база данных-получатель может успевать за соответствующей базой данных-источником, любая другая база данных-получатель в любой момент может отставать. Режим асинхронной фиксации полезен для сценария аварийного восстановления, в котором первичная и вторичная реплики находятся на значительном расстоянии друг от друга, и когда необходимо, чтобы на работу первичной реплики не влияли небольшие ошибки. Также подобный режим полезен в тех ситуациях, когда производительность значительно важнее защиты данных, обеспечиваемой синхронной записью изменений. Кроме того, так как первичная реплика не ожидает подтверждения из вторичной реплики, проблемы во вторичной реплике никогда не влияют на первичную реплику.
Вторичная реплика асинхронной фиксации пытается соответствовать записям журнала, получаемых от первичной реплики. Однако базы данных-получатели асинхронной фиксации всегда остаются несинхронизированными и могут несколько отставать от соответствующих баз данных-источников. Как правило, разрыв между базой данных-получателем асинхронной фиксации и соответствующей базой данных-источником незначителен. Однако этот разрыв может стать существенным, если сервер, содержащий вторичную реплику, перегружен или у сети низкая пропускная способность.
В режиме асинхронной фиксации поддерживается только принудительная отработка отказа (с возможной потерей данных). Принудительная отработка отказа — это последний курорт, предназначенный только для ситуаций, в которых текущая первичная реплика будет оставаться недоступной в течение длительного периода, а немедленная доступность баз данных-источника является более критической, чем риск возможной потери данных. Целевой объект отработки отказа должен быть репликой, роль которой находится в состоянии SECONDARY или RESOLVING. Цель отработки отказа принимает первичную роль, а ее копии баз данных станут при этом базами данных-источниками. Все остальные базы данных-получатели и бывшая база данных-источник (как только она вновь становится доступной) приостанавливаются. Затем потребуется ручное возобновление работы каждой из них. В режиме асинхронной фиксации все журналы транзакций, которые первоначальная первичная реплика не отправила вторичной реплике, будут потеряны. Это означает, что в некоторых или во всех новых базах данных-источниках могут отсутствовать транзакции, которые были зафиксированы недавно. Дополнительные сведения о том, как выполняется принудительная отработка отказа, и об оптимальных методах ее использования см. в статье Отработка отказа и режимы отработки отказа (группы доступности Always On).
Synchronous-Commit Availability Mode
В режиме доступности с синхронной фиксацией (режим синхронной фиксации) после присоединения к группе доступности база данных-получатель синхронизируется с соответствующей базой данных-источником и переходит в состояние SYNCHRONIZED. База данных-получатель остается в состоянии SYNCHRONIZED, пока продолжается синхронизация данных. Это гарантирует, что все транзакции, зафиксированные в данной базе данных-источнике, также будут зафиксированы в соответствующей базе данных-получателе. Когда все базы данных-получатели данной вторичной реплики синхронизированы, вторичная реплика имеет общее состояние работоспособности синхронизации HEALTHY.
В этом разделе.
Режим синхронной фиксации только с переходом на другой ресурс вручную
Режим синхронной фиксации с автоматическим переходом на другой ресурс
Факторы, нарушающие синхронизацию данных
После синхронизации всех баз данных вторичная реплика переходит в состояние HEALTHY. Синхронизированная вторичная реплика остается в исправном состоянии, если не происходят никакие из следующих событий.
Задержка или сбой в сети или компьютере приводит к истечении времени ожидания сеанса между вторичной репликой и первичной репликой.
Примечание.
Сведения о свойстве ожидания сеанса для реплик доступности см. в статье Что такое группа доступности Always On?.
Пользователь приостанавливает базу данных-получатель на вторичной реплике. Вторичная реплика теряет синхронизацию и переходит в состояние работоспособности синхронизации 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, и первичная реплика прекращает ожидание подтверждения от вторичной реплики. Это позволяет избежать ситуации, в которой сбойная вторичная реплика синхронной фиксации препятствует фиксации журнала транзакций в первичной реплике.
Режим с синхронной фиксацией защищает данные за счет того, что требует их синхронизации между двумя экземплярами. Делается это за счет некоторого увеличения задержки транзакции.
Режим синхронной фиксации только с переходом на другой ресурс вручную
Если между этими репликами имеется подключение и база данных синхронизирована, то поддерживается переход на другой ресурс вручную. Если работа вторичной реплики нарушается, то это никак не сказывается на первичной реплике. Первичная реплика не защищена, если ни одна реплика не находится в состоянии SYNCHRONIZED (то есть когда она не отправляет данные ни одной вторичной реплике). Если работа первичной реплики нарушается, вторичные реплики переходят в состояние RESOLVING, но владелец базы данных может принудительно выполнить отработку отказа на вторую реплику (с возможной потерей данных). Дополнительные сведения см. в разделе Отработка отказа и режимы отработки отказа (группы доступности Always On).
Режим синхронной фиксации с автоматическим переходом на другой ресурс
Автоматический переход на другой ресурс обеспечивает высокий уровень доступности за счет того, что доступ к базам данных быстро восстанавливается после потери первичной реплики. Чтобы настроить группу доступности для автоматического перехода на другой ресурс, нужно задать для текущей первичной реплики и хотя бы одной вторичной реплики режим синхронной фиксации с автоматическим переходом на другой ресурс. SQL Server 2019 (15.x) увеличил максимальное число синхронных реплик до 5, начиная с 3 в SQL Server 2017 (14.x). Вы можете настроить эту группу из пяти реплик для автоматического перехода на другой ресурс в пределах группы. Предоставляется одна первичная реплика и четыре синхронные вторичные реплики.
Кроме того, для автоматического перехода на другой ресурс в заданный момент вторичная реплика должна быть синхронизирована с первичной репликой (это значит, что все базы данных-получатели синхронизированы), а кластер WSFC должен иметь кворум. Если первичная реплика становится недоступной при описанных выше условиях, происходит автоматический переход на другой ресурс. Вторичная реплика переключается в роль первичной и предлагает свои базы данных как базы данных-источники. Дополнительные сведения об автоматической отработке отказа см. в статье Отработка отказа и режимы отработки отказа (группы доступности Always On).
Примечание.
Дополнительные сведения о кворуме WSFC и группах доступности Always On см. в статье Режимы кворума WSFC и участвующая в голосовании конфигурация (SQL Server).
Задержка данных на вторичной реплике
Применение доступа только для чтения ко вторичным репликам полезно, если для нагрузок, связанных с операциями с ними, приемлема некоторая задержка данных. В ситуациях, когда задержка данных неприемлема, рассмотрите возможность выполнения рабочих нагрузок только чтения за счет первичной реплики.
Из основной реплики выполняется отправка журнала изменений в базе данных-источнике на вторичные реплики. На каждой базе данных-получателе выделенный поток повтора применяет записи журнала. В базе данных, доступной для чтения, каждое изменение данных не появляется среди результатов запроса до тех пор, пока запись журнала о данном изменении не будет применена к базе данных-получателю, а транзакция не будет зафиксирована в базе данных-источнике.
Это означает, что между первичной и вторичной репликами возникает некоторая задержка, обычно порядка нескольких секунд. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных. Для отслеживания приостановок перемещения данных можно использовать Панель управления AlwaysOn или динамическое административное представление sys.dm_hadr_database_replica_states.
Дополнительные сведения об изучении задержки повтора на вторичной реплике см. в разделе Устранение неполадок при отсутствии повтора изменений в источнике на вторичной реплике.
Связанные задачи
Изменение режима доступности и режима отработки отказа
Изменение режима доступности реплики доступности (SQL Server)
Изменение режима отработки отказа реплики доступности (SQL Server)
Настройка голосов кворума
Отработки отказа вручную
Выполнение запланированного перехода на другой ресурс вручную для группы доступности (SQL Server)
Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server)
Используйте мастер группы доступности отработки отказа (SQL Server Management Studio)
Просмотр состояний групп доступности, реплик доступности и баз данных
См. также
См. также
Обзор групп доступности Always On (SQL Server)
Режимы отработки отказа и отработки отказа (группы доступности AlwaysOn)
Отказоустойчивая кластеризация Windows Server (WSFC) с использованием SQL Server