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

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

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

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

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

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

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

  Дополнительные сведения о принудительном создании кворума см. в разделе Аварийное восстановление WSFC через принудительный кворум (SQL Server). Дополнительные сведения о причинах необходимости выполнения принудительной отработки отказа после принудительного создания кворума см. в разделе Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).

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

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

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

• Перед началом работы:  

  Ограничения

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

  Рекомендации

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

  Безопасность

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

  Среда SQL Server Management Studio

  Transact-SQL

  PowerShell

• Дальнейшие действия.  Основные задачи после принудительной отработки отказа

• Пример сценария:  Использование принудительной отработки отказа для восстановления после разрушительного сбоя

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

• См. также

Перед началом работы

Ограничения

• Единственный случай, когда нельзя выполнить принудительную отработку отказа, — кластер отказоустойчивого кластера Windows Server (WSFC) нет имеет кворума.

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

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

• Команда отработки отказа завершает работу сразу после того, как цель перехода принимает команду. Однако восстановление базы данных происходит асинхронно после того, как группа доступности закончит отработку отказа.

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

  Примечание
  Транзакции между базами данных и распределенные транзакции не поддерживаются в Группы доступности AlwaysOn. Дополнительные сведения см. в разделе Транзакции между базами данных не поддерживаются при зеркальном отображении баз данных или в группах доступности AlwaysOn (SQL Server).

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

• В кластере WSFC есть кворум. Если у кластера нет кворума, см. раздел Аварийное восстановление WSFC через принудительный кворум (SQL Server).

• Необходимо иметь возможность подключения к экземпляру сервера, на котором размещена реплика, роль которой находится в состоянии SECONDARY или RESOLVING.

Рекомендации

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

• Если это возможно, выполняйте принудительный переход только на те цели перехода, базы данных-получатели которых имеют состояние NOT SYNCHRONIZED, SYNCHRONIZED или SYNCHRONIZING. Сведения о последствиях принудительной отработки отказа, когда база данных-получатель находится в состоянии INTIAILIZING или REVERTING, см. в разделе Ограничения ранее в этом разделе.

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

  Совет

  Для сравнения значений номеров LSN конца журнала подключитесь по очереди к каждой работающей вторичной реплике и определите значение end_of_log_lsn каждой локальной базы данных-получателя с помощью запроса к представлению sys.dm_hadr_database_replica_states. Затем сравните значения номеров LSN конца журнала для различных копий каждой базы данных. Обратите внимание: высшие значения номеров LSN для разных баз данных могут находиться на разных вторичных репликах. В этом случае выбор целевого места для отработки отказа зависит от относительной важности данных в различных базах данных. Другими словами, следует определить, для какой базы данных нужнее всего минимизировать возможность потери данных.

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

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

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

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

  Если кворум теряется и принудительное восстановление кворума 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 может не отражать действительного состояния кластера в момент перехода первичной реплики в режим «вне сети». Поэтому значение is_failover_ready, только если узел размещения на момент сбоя был в рабочем состоянии. Дополнительные сведения см. в подразделе «Почему принудительная отработка отказа необходима после принудительного создания кворума» раздела Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).

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

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

  Примечание

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

Безопасность

Разрешения

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

[В начало]

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

Принудительная отработка отказа (с возможной потерей данных)

1. В обозревателе объектов подключитесь к экземпляру сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и на которую нужно выполнить переход, и разверните дерево сервера.

2. Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности.

3. Щелкните правой кнопкой мыши группу доступности для выполнения отработки отказа и выберите команду Отработка отказа.

4. Будет запущен мастер отработки отказа группой доступности. Дополнительные сведения см. в разделе Использование мастера отработки отказа группы доступности (Среда SQL Server Management Studio).

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

[В начало]

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

Принудительная отработка отказа (с возможной потерей данных)

1. Подключитесь к экземпляру сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и на которую нужно выполнить переход.

2. Используйте инструкцию ALTER AVAILABILITY GROUP следующим образом:

   ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   где group_name — это имя группы доступности.

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

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

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

[В начало]

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

Принудительная отработка отказа (с возможной потерей данных)

1. Перейдите в каталог (cd) экземпляра сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и на которую нужно выполнить переход.

2. Используйте командлет 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. Дополнительные сведения см. в разделе Получение справок по SQL Server PowerShell.

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

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

• SQL Server PowerShell, поставщик

[В начало]

Дальнейшие действия. Основные задачи после принудительной отработки отказа

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

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

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

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

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

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

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

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

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

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

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

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

2. После принудительной отработки отказа приостанавливаются все базы данных-получатели. Это относится к бывшим базам данных-источникам, для которых бывшая первичная реплика вновь переходит в режим «в сети» и обнаруживает, что отныне является вторичной репликой. Необходимо вручную возобновить работу каждой приостановленной базы данных во вторичной реплике.

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

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

   Создание моментального снимка базы данных

   • создать моментальный снимок базы данных (Transact-SQL)

   Возобновление базы данных доступности

   • Возобновление базы данных доступности (SQL Server)

   Внимание!

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

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

   Удаление вторичной реплики

   • Удаление вторичной реплики из группы доступности (SQL Server)

4. Если необходима принудительная отработка отказа с одной или несколькими дополнительными принудительными отработками отказа, выполняйте резервное копирование журналов после каждой дополнительной принудительной отработки отказа. О том, по каким причинам это необходимо, см. пункт «Риск использования принудительной отработки отказа» в подразделе «Принудительный переход на другой ресурс вручную (с возможной потерей данных)» раздела Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).

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

   • Создание резервной копии журнала транзакций (SQL Server)

[В начало]

Пример сценария: Использование принудительной отработки отказа для восстановления после разрушительного сбоя

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

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

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

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

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

• Реакция на разрушительный сбой в основном центре обработки данных

• Восстановление изначальной топологии группы доступности

Реакция на разрушительный сбой в основном центре обработки данных

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

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

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

[В начало]

Восстановление изначальной топологии группы доступности

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

Важно!

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

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

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

[В начало]

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

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

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

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

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

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

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

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

Сведения для поиска и устранения неполадок

• Поиск и устранение неисправностей конфигурации групп доступности AlwaysOn (SQL Server)

• Устранение неполадок с операцией добавления файла, давшей сбой (группы доступности AlwaysOn)

[В начало]

См. также

• **Блоги: **

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

  Блоги инженеров CSS SQL Server

• **Технические документы: **

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

  Технические документы Майкрософт Microsoft по SQL Server 2012

  Технические документы группы консультантов по SQL Server

[В начало]

См. также

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

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

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

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

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

Отслеживание групп доступности (SQL Server)

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