Поделиться через

Выполнение принудительного ручного переключения для группы доступности 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. Для получения дополнительной информации см. Транзакции между базами данных и распределенные транзакции для групп доступности Always On и зеркального отображения баз данных (SQL Server).

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

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

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

  • Если это возможно, выполняйте принудительное переключение только на те целевые узлы аварийного переключения, вторичные базы данных которых находятся в состояниях НЕ СИНХРОНИЗИРОВАНО, СИНХРОНИЗИРОВАНО или СИНХРОНИЗАЦИЯ. Смотрите сведения о последствиях принудительного переключения при отказе, когда вторичная база данных находится в состоянии INITIALIZING или REVERTING, в разделе Ограничения и ограничения, ранее в этом разделе.

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

    Совет

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

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

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

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

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

    Если кворум теряется и принудительное восстановление кворума 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 надлежащее, только если узел размещения на момент сбоя был в рабочем состоянии. Для получения дополнительной информации см. раздел "Почему необходимо принудительное отработку отказа после создания кворума" в статье Отработка отказа и режимы отработки отказа (группы доступности 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 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 имя_группы FORCE_FAILOVER_ALLOW_DATA_LOSS

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

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

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

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

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

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

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

  2. Используйте командлет Switch-SqlAvailabilityGroup с параметром AllowDataLoss в одной из следующих форм:

    • -РазрешитьПотерюДанных

      По умолчанию параметр -AllowDataLoss заставляет Switch-SqlAvailabilityGroup напомнить вам о том, что принудительное переключение может привести к потере незавершенных транзакций и потребует подтверждения. Чтобы продолжить, введите букву Y; чтобы отменить операцию, введите букву N.

      В следующем примере выполняется принудительное переключение (с возможной потерей данных) группы доступности MyAg на вторичную реплику на экземпляре сервера с именем SecondaryServer\InstanceName. Будет предложено подтвердить эту операцию.

      Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss

    • -ДопуститьПотерюДанных-Принудительно

      Чтобы инициировать принудительное переключение при отказе без подтверждения, укажите параметры -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.

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

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

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

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

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

      Примечание.

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

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

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

      Примечание.

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

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

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

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

    Внимание

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

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

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

    Внимание

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

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

    Удалить вторичную реплику

  4. Если необходима принудительная отработка отказа с одной или несколькими дополнительными принудительными отработками отказа, выполняйте резервное копирование журналов после каждой дополнительной принудительной отработки отказа. Причины этого описаны в разделе "Риски принудительной отработки отказа" в пункте "Принудительная ручная отработка отказа (с возможной потерей данных)" статьи Отработка отказа и режимы отработки отказа (группы доступности 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 (Transact-SQL) (Сделайте запрос к столбцу end_of_log_lsn. Дополнительные сведения см. в разделе Рекомендации ранее в этой статье.)
3. DBA вручную возобновляет работу каждой вторичной базы данных на существующей вторичной реплике. Возобновление базы данных доступности (SQL Server)

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

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

Внимание

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

Действия по восстановлению группы к ее изначальной топологии

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

Этап Ссылки.
1. Узлы в основном центре обработки данных вновь запускаются и восстанавливают связь с кластером WSFC. Их реплики доступности переходят в режим «в сети» в качестве вторичных реплик с приостановленными базами данных; DBA предстоит вручную возобновить работу каждой из этих баз данных. Возобновление базы данных доступности (SQL Server)

Совет. Во избежание потери данных в базах данных, ставших основными после отработки отказа, следует попытаться создать моментальный снимок базы данных на приостановленных базах данных на одной из вторичных баз данных с синхронной фиксацией. Имейте в виду, что усечение журнала транзакций на основной базе данных задерживается, если хотя бы одна из её вторичных баз данных приостановлена. Кроме того, состояние вторичной реплики с синхронной фиксацией не может перейти в HEALTHY до тех пор, пока хотя бы одна из локальных баз данных остается приостановленной.
2. После возобновления работы баз данных DBA временно изменяет режим новой первичной реплики на режим с синхронной фиксацией. Данное действие состоит из следующих шагов:

1) Изменение режима фиксации одной из реплик доступности в режиме "вне сети" на асинхронный.

2) Переведите новую первичную реплику в режим синхронной фиксации. Примечание. Данный шаг позволяет вторичным базам данных с синхронной фиксацией перейти в состояние 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 подключается к новой первичной реплике и выполняет следующие действия:

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

2) Изменяет режим фиксации вторичной реплики в основном центре обработки данных с асинхронного обратно на синхронный.		 Изменение режима доступности реплики доступности (SQL Server)

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

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

Запланированное ручное переключение:

Для устранения неполадок:

Связанный контент

См. также

Обзор групп доступности Always On (SQL Server)
Режимы доступности (группы доступности AlwaysOn)
Сбой и режимы автоматического переключения (группы доступности Always On)
О подключении клиента к репликам доступности (SQL Server)
Мониторинг групп доступности (SQL Server)
Отказоустойчивая кластеризация Windows Server (WSFC) с использованием SQL Server