Выполнение принудительного переключения вручную группы доступности Always On (SQL Server)

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

В этой статье описывается, как выполнить принудительное переключение (с возможной потерей данных) в группе доступности Always On при помощи SQL Server Management Studio, Transact-SQL или PowerShell в SQL Server. Принудительное переключение — это форма ручного переключения, предназначенная строго для аварийного восстановления, когда плановая ручная отработка отказа невозможна. Если выполняется принудительный переход на несинхронизированную вторичную реплику, возможна потеря данных. Поэтому мы настоятельно рекомендуем принудительное переключение на отказоустойчивость только в том случае, если необходимо немедленно восстановить работу группы доступности и вы готовы пойти на риск потери данных.

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

Внимание

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

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

После принудительного создания кворума в кластере WSFC (принудительный кворум) необходимо выполнить принудительное переключение на резервную копию каждой группы доступности (с возможной потерей данных). Принудительное переключение на резерв необходимо, поскольку реальное состояние кластера WSFC могло быть потеряно. Однако можно избежать потери данных, если вы можете принудительно выполнить отработку отказа на экземпляре сервера, на котором размещена реплика, которая была первичной репликой, прежде чем принудительно выполнить кворум или вторичную реплику, которая была синхронизирована до принудительного кворума. Дополнительные сведения см. в статье "Возможные способы предотвращения потери данных после принудительного использования кворума" далее в этой статье.

Внимание

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

Дополнительные сведения о принудительном создании кворума см. в статье Аварийное восстановление WSFC через принудительный кворум (SQL Server). Дополнительные сведения о том, почему после принудительного создания кворума требуется принудительная отработка отказа, см. в статье Отработка отказа и режимы отработки отказа (группы доступности Always On).
Если первичная реплика становится недоступной, а кластер WSFC работает с кворумом, вы можете принудительно выполнить отработку отказа (с возможной потерей данных) на любую реплику, роль которой находится в состоянии SECONDARY или RESOLVING. Если возможно, выполните принудительный переход на вторичную реплику с синхронной фиксацией, которая была синхронизирована в момент потери первичной реплики.

Совет

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

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

Ограничения

Единственный случай, когда невозможно выполнить принудительное переключение на другой узел, это когда кластер отказоустойчивости Windows Server (WSFC) не имеет кворума.
При принудительном переключении на другую группу доступности возможна потеря данных. Помимо этого, если первичная реплика работает во время запуска принудительного переключения, клиенты могут сохранить соединение с бывшими первичными базами данных. Поэтому настоятельно рекомендуется принудительно выполнить отработку отказа только если первичная реплика больше не функционирует, и вы готовы рисковать потерей данных, чтобы восстановить доступ к базам данных в группе доступности.
Если вторичная база данных находится в состоянии REVERTING или INITIALIZING, принудительное выполнение отказа приведет к тому, что база данных не сможет запуститься как основная база данных. Если база данных была в INITIALIZING состоянии, необходимо применить отсутствующие записи журнала из резервной копии базы данных или полностью восстановить базу данных с нуля. Если база данных была в REVERTING состоянии, необходимо полностью восстановить базу данных из резервных копий.
Команда переключения на резерв возвращает управление сразу после того, как резервная цель приняла команду. Однако восстановление базы данных происходит асинхронно после того, как группа доступности завершит процедуру переключения.
Согласованность данных между базами данных в группе доступности в случае переключения в случае отказа может не поддерживаться.

Примечание.

Поддержка транзакций между базами данных и распределенных транзакций зависит от версий операционной системы и SQL Server. Дополнительные сведения см. в разделе "Транзакции — группы доступности" и зеркальное отображение базы данных.

Предварительные условия

В кластере WSFC есть кворум. Если у кластера нет кворума, см. статью Аварийное восстановление WSFC через принудительный кворум (SQL Server).
Необходимо подключиться к экземпляру сервера, на котором размещена реплика, роль которой находится в состоянии SECONDARY или RESOLVING.

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

В некоторых условиях сбоя после потери кворума можно предотвратить потерю данных следующим образом:

Если исходная первичная реплика станет доступной в сети

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

Если кворум потерян и принудительное восстановление кворума WSFC приводит к восстановлению узла кластера, на котором размещена синхронизированная вторичная реплика группы доступности, то потерю данных для этой группы доступности можно предотвратить. Если восстановленный узел был активен в момент потери кворума, вы можете определить, возможна ли потеря данных в данной базе данных, запрашивая столбец is_failover_ready динамического административного представления sys.dm_hadr_database_replica_cluster_states. Например, для экземпляра сервера с именем sql108w2k8r22, выполните следующий запрос:
```
SELECT *
FROM sys.dm_hadr_database_replica_cluster_states
WHERE replica_id = (
    SELECT replica_id
    FROM sys.availability_replicas
    WHERE replica_server_name = 'sql108w2k8r22'
);
```
Внимание

Если восстановленный узел не работал в момент потери кворума, is_failover_ready может не отразить фактическое состояние кластера в момент, когда первичная реплика стала недоступна. Поэтому значение актуально только если узел хоста в момент сбоя. Для получения дополнительной информации см. раздел "Почему необходимо принудительное отработку отказа после создания кворума" в статье Отработка отказа и режимы отработки отказа (группы доступности Always On).

Если is_failover_ready = 1 база данных помечена как синхронизированная в кластере и готова к аварийному переключению. Если is_failover_ready = 1 на каждой базе данных данной вторичной реплики, можно выполнить принудительное переключение (FORCE_FAILOVER_ALLOW_DATA_LOSS) без потери данных на этой вторичной реплике. Синхронизированная вторичная реплика перейдет в режим «в сети» в первичной роли как новая первичная реплика с неповрежденными данными.

Если is_failover_ready = 0 база данных не помечена как синхронизированная в кластере и не готова к планируемому ручному переключению на резервный сервер. При принудительном переключении на вторичную реплику узла-хоста в этой базе данных произойдет потеря данных.

Примечание.

При принудительном переключении на вторичную реплику объем потери данных зависит от того, насколько далеко целевая реплика для переключения отстает от основной реплики. К сожалению, когда кластер WSFC не имеет кворума или кворум был принудительно установлен, вы не можете оценить объем возможной потери данных. Однако после восстановления работоспособности кворума кластера WSFC можно начать отслеживать возможную потерю данных. Дополнительные сведения см. в разделе "Мониторинг возможной потери данных" в Резервные переключения и режимы резервных переключений (группы доступности Always On).

Разрешения

Требуется ALTER AVAILABILITY GROUP разрешение на группу доступности, разрешение, CONTROL AVAILABILITY GROUPALTER ANY AVAILABILITY GROUP разрешение или CONTROL SERVER разрешение.

Использование SQL Server Management Studio

В обозревателе объектов подключитесь к экземпляру сервера, где размещена реплика, роль которой имеет состояние SECONDARY или RESOLVING в группе доступности, которой необходимо выполнить отработку отказа, и разверните дерево сервера.
Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности .
Щелкните правой кнопкой мыши на группе доступности для отработки отказа и выберите команду Отработка отказа.
Запускается мастер групп доступности с переключением при сбое. Дополнительные сведения см. в разделе Использование мастера переключения группы доступности (SQL Server Management Studio).
После принудительного переключения группы доступности выполните необходимые действия. Дополнительные сведения см. в разделе «Выполнение дальнейших действий: основные задачи после принудительного переключения» далее в этой статье.

Использование Transact-SQL

Подключитесь к экземпляру сервера, который размещает реплику, роль и состояние которой находятся в SECONDARY или RESOLVING в группе доступности, в которой необходимо выполнить отработку отказа.
Используйте инструкцию ALTER AVAILABILITY GROUP , как показано ниже, где group_name — имя группы доступности:

ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

Следующий пример принуждает группу доступности AccountsAG переключиться на локальную вторичную реплику.
```
ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
После принудительного переключения группы доступности выполните необходимые действия. Дополнительные сведения см. в разделе «Основные задачи после форсированного отказа» в дальнейшем тексте этой статьи.

Использование PowerShell

Измените директорию (cd) на экземпляр сервера, на котором размещена реплика, роль которой находится в состоянии SECONDARY или RESOLVING в группе доступности, которую необходимо выполнить отработку отказа.
Используйте командлет Switch-SqlAvailabilityGroup с параметром AllowDataLoss одним из следующих способов:
- -AllowDataLoss
  
  По умолчанию параметр -AllowDataLoss заставляет Switch-SqlAvailabilityGroup запросить вас о том, что принудительное переключение может привести к потере незафиксированных транзакций и требует подтверждения. Чтобы продолжить, введите Y; для отмены операции введите N.
  
  В следующем примере выполняется принудительное переключение (с возможной потерей данных) группы доступности MyAg на вторичную реплику на экземпляре сервера с именем SecondaryServer\InstanceName. Вам будет предложено подтвердить эту операцию.
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss
```
- -AllowDataLoss-Force
  
  Чтобы инициировать принудительное переключение без подтверждения, укажите оба параметра -AllowDataLoss и -Force. Это полезно, если нужно включить команду в скрипт и запустить ее без взаимодействия с пользователем. Однако используйте параметр -Force с осторожностью, так как принудительная отработка отказа может привести к потере данных из баз данных, участвующих в группе доступности.
  
  В следующем примере группа доступности MyAg выполняет принудительное переключение (с возможной потерей данных) на экземпляр сервера, именуемый SecondaryServer\InstanceName. Параметр -Force подавляет подтверждение этой операции.
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss -Force
```
Примечание.

Чтобы просмотреть синтаксис командлета, используйте командлет Get-Help в среде SQL Server PowerShell. Дополнительные сведения см. в разделе Get Help SQL Server PowerShell.
После принудительного переключения группы доступности выполните необходимые действия. Дополнительные сведения см. в разделе "Дальнейшие действия: основные задачи после принудительной отработки отказа" далее в этой статье.

Настройка и использование поставщика SQL Server PowerShell

Поставщик SQL Server PowerShell

Последующие шаги: Основные задачи после принудительного перехода на резервный сервер

После принудительного переключения на вторичную реплику, она становится новой первичной репликой. Однако, чтобы сделать эту реплику доступности доступной клиентам, может потребоваться повторная настройка WSFC-кворума или регулировка конфигурации режима доступности для группы доступности.
- Если отработка отказа выполнена за пределами группы автоматического перехода на другой ресурс, настройте голоса кворума на узлах WSFC так, чтобы они соответствовали новой конфигурации группы доступности. Если узел WSFC, на котором размещена целевая вторичная реплика, не имеет голоса кворума WSFC, может потребоваться принудительно применить кворум WSFC.
  
  Набор автоматического переключения существует только в том случае, если две реплики доступности (включая предыдущую первичную реплику) настроены для режима синхронной фиксации транзакций с автоматическим переключением.
  
  Настройка голосов кворума
- Если вы выполнили отработку отказа за пределами группы отказоустойчивости с синхронной фиксацией: мы рекомендуем рассмотреть возможность настройки режима доступности и режима отказоустойчивости на новой первичной реплике и на оставшихся вторичных репликах, чтобы обеспечить нужную конфигурацию с синхронной фиксацией и автоматической отработкой отказа.
  
  Примечание.
  
  Набор отработки отказа синхронной фиксации существует только в том случае, если текущая первичная реплика настроена для режима синхронной фиксации.
  
  Изменение режима доступности и режима отработки отказа
  - Изменение режима доступности реплики в группе доступности AlwaysOn
  - Измените режим переключения при отказе для реплики в группе доступности Always On
После принудительного переключения на резервный сервер приостанавливаются все вторичные базы данных. К ним относятся бывшие первичные базы данных после того, как бывшая первичная реплика снова подключается и обнаруживает, что она теперь является вторичной репликой. Необходимо вручную возобновить работу каждой приостановленной базы данных на каждой вторичной реплике.

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

Внимание

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

Чтобы создать моментальный снимок базы данных
- Создание моментального снимка базы данных (Transact-SQL)
Возобновление базы данных доступности
- Возобновление базы данных доступности (SQL Server)
Внимание

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

Удалить вторичную реплику
- Удалите вторичную реплику из группы доступности (SQL Server)
Если необходима принудительная отработка отказа с одной или несколькими дополнительными принудительными отработками отказа, выполняйте резервное копирование журналов после каждой дополнительной принудительной отработки отказа. Причины этого описаны в разделе "Риски принудительной отработки отказа" в пункте "Принудительная ручная отработка отказа (с возможной потерей данных)" статьи Отработка отказа и режимы отработки отказа (группы доступности Always On).

Создание резервной копии журнала
- Резервное копирование журнала транзакций

Пример сценария: использование принудительного переключения для восстановления после катастрофического сбоя

В случае отказа первичной реплики и отсутствия синхронизированной вторичной реплики может быть целесообразно принудительно переключить группу доступности. Правильность принудительной отработки отказа зависит от: (1) считаете ли вы, что первичная реплика будет отключена дольше, чем позволяет ваше соглашение об уровне обслуживания (SLA), и (2) готовы ли вы рисковать потенциальной потерей данных, чтобы быстро сделать доступными первичные базы данных. Если вы решили, что для группы доступности необходимо принудительное переключение, само принудительное переключение является лишь одним из этапов многошагового процесса.

Чтобы проиллюстрировать шаги, необходимые для принудительного переключения в случае отказа с целью восстановления после катастрофического сбоя, в этой статье представлен один из возможных сценариев аварийного восстановления. Данный сценарий подразумевает наличие группы доступности, изначальная топология которой состоит из основного центра обработки данных, где размещены три реплики доступности с синхронной фиксацией (в том числе первичная реплика), и удаленного центра обработки данных, где размещены две вторичные реплики с асинхронной фиксацией. На следующем рисунке изображена изначальная топология группы доступности в данном примере: Группа доступности размещается в кластере WSFC со несколькими подсетями; три узла находятся в основном центре обработки данных (Node 01, Node 02и Node 03), и два узла в удаленном центре обработки данных (Node 04 и Node 05).

Схема исходной топологии группы доступности.

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

Схема топологии после сбоя основного центра обработки данных.

Администратор баз данных (DBA) принимает решение о принудительном перемещении группы доступности на одну из удаленных вторичных реплик с асинхронной фиксацией. В данном примере приведены типичные шаги для принудительного переключения группы доступности на удаленную реплику и последующего возврата группы к изначальной топологии.

Представленные ниже ответные действия после сбоя состоят из следующих двух этапов:

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

Реагирование на катастрофический сбой основного центра обработки данных

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

Схема шагов реагирования на ошибку основного центра обработки данных.

На данном рисунке указаны следующие шаги:

Этап	Действие	Ссылки.
`1.`	Администратор баз данных (DBA) или сетевой администратор гарантирует здоровое состояние кворума в кластерной среде WSFC. В данном примере необходим принудительный кворум.	Режимы кворума WSFC и конфигурация голосования (SQL Server) Восстановление WSFC после сбоя через принудительный кворум (SQL Server)
`2.`	DBA подключается к экземпляру сервера с наименьшей задержкой (Node 04) и выполняет принудительное ручное переключение. В результате принудительного переключения эта вторичная реплика становится первичной, а вторичные базы данных на оставшейся вторичной реплике (Node 05) приостанавливаются.	sys.dm_hadr_database_replica_states (запрос столбца end_of_log_lsn . Дополнительные сведения см. в разделе "Рекомендации" ранее в этой статье.)
`3.`	DBA вручную возобновляет работу каждой вторичной базы данных на существующей вторичной реплике.	Возобновление базы данных доступности (SQL Server)

Возврат группы доступности в исходную топологию

На следующем рисунке показана последовательность действий для восстановления изначальной топологии группы доступности после возобновления работы основного центра обработки данных и восстановления связи узлов WSFC с кластером WSFC.

Внимание

Если кворум кластера WSFC был принудительно установлен, автономные узлы могут сформировать новый кворум при перезагрузке, если выполняются следующие условия: (a) отсутствует сетевое подключение между любыми узлами в наборе принудительного кворума, и (b) перезагружающиеся узлы составляют большинство узлов кластера. Это приведет к состоянию «разделенного мозга», при котором группа доступности будет иметь две независимые первичные реплики, каждая в своем центре обработки данных. Прежде чем создавать кворумное меньшинство с помощью принудительного кворума, изучите статью Аварийное восстановление WSFC через принудительный кворум (SQL Server).

Схема шагов для возврата группы в исходную топологию.

На данном рисунке указаны следующие шаги:

Этап	Действие	Ссылки.
`1.`	Узлы в основном центре обработки данных вновь запускаются и восстанавливают связь с кластером WSFC. Их реплики доступности будут подключены как вторичные реплики с приостановленными базами данных, и DBA необходимо вручную возобновить каждую из этих баз данных в ближайшее время.	Возобновление базы данных доступности (SQL Server) Совет. Если вы обеспокоены возможной потерей данных в основных базах данных после переключения, необходимо попытаться создать моментальный снимок базы данных на приостановленных базах данных в одной из вторичных баз данных с синхронной фиксацией. Имейте в виду, что усечение журнала транзакций на основной базе данных задерживается, если хотя бы одна из её вторичных баз данных приостановлена. Кроме того, состояние синхронизации вторичной реплики синхронного подтверждения не может перейти в состояние `HEALTHY`, пока любая локальная база данных остается приостановленной.
`2.`	После возобновления работы баз данных DBA временно изменяет режим новой первичной реплики на режим с синхронной фиксацией. Данное действие состоит из следующих шагов: 1. Измените одну реплику доступности в режиме оффлайн на режим асинхронной фиксации. 2. Переключите новую первичную реплику в режим синхронной фиксации. Заметка: Этот шаг позволяет вторичным базам данных с синхронной фиксацией `SYNCHRONIZED` стать активными.	Изменение режима доступности реплики в группе доступности AlwaysOn
`3.`	После того как вторичная реплика синхронной фиксации на узле 03 (исходная первичная реплика) вступает `HEALTHY` в состояние синхронизации, DBA выполняет плановое ручное переключение на эту реплику, чтобы сделать ее первичной репликой снова. Реплика на узле Node 04 вновь становится вторичной.	sys.dm_hadr_database_replica_states Использование политик AlwaysOn для просмотра работоспособности группы доступности (SQL Server) Выполнение запланированного переключения на резервный ресурс вручную для группы доступности Always On (SQL Server)
`4.`	DBA подключается к новой первичной реплике и выполняет следующие действия: 1. Переводит бывшую первичную реплику (в удаленном центре) обратно в режим асинхронной фиксации. 2. Изменяет вторичную реплику с асинхронной фиксацией в основном центре обработки данных на режим синхронной фиксации.	Изменение режима доступности реплики в группе доступности AlwaysOn

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

Плановое переключение на резервную систему вручную

Troubleshoot

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-10-06