Выполнение принудительного перехода на другой ресурс вручную для группы доступности Always On (SQL Server)Perform a Forced Manual Failover of an Always On Availability Group (SQL Server)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL Azure нетAzure Synapse Analytics (хранилище данных SQL) нетParallel Data Warehouse APPLIES TO: yesSQL Server noAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

В этом разделе описывается выполнение принудительной отработки отказа (с возможной потерей данных) в группе доступности AlwaysOn с использованием SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQLили PowerShell в SQL ServerSQL Server.This topic describes how to perform a forced failover (with possible data loss) on an Always On availability group by using SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL, or PowerShell in SQL ServerSQL Server. Принудительная отработка отказа — это форма перехода на другой ресурс вручную, предназначенная исключительно для аварийного восстановления в случаях, когда невозможно выполнить запланированную отработку отказа вручную .A forced failover is a form of manual failover that is intended strictly for disaster recovery, when a planned manual failover is not possible. Если выполняется принудительный переход на несинхронизированную вторичную реплику, возможна потеря данных.If you force failover to an unsynchronized secondary replica, some data loss is possible. Поэтому мы настоятельно рекомендуем выполнять принудительную отработку отказа только в том случае, если необходимо немедленно возобновить работу группы доступности и вы готовы пойти на риск потери данных.Therefore, we strongly recommend that you force failover only if you must restore service to the availability group immediately and you are willing to risk losing data.

После принудительной отработки отказа цель перехода, на которую перешла группа доступности, становится новой первичной репликой.After a forced failover, the failover target to which the availability group was failed over becomes the new primary replica. Базы данных-получатели на оставшихся вторичных репликах приостанавливаются и должны быть восстановлены вручную.The secondary databases in the remaining secondary replicas are suspended and must be manually resumed. Если прежняя первичная реплика станет доступной, то она переключится в роль вторичной, в связи с чем бывшие базы данных-источники станут базами данных-получателями и перейдут в состояние SUSPENDED.When the former primary replica becomes available, it transitions to the secondary role, causing the former primary databases to become secondary databases and transition into the SUSPENDED state. Перед возобновлением работы данной базы данных-получателя можно попробовать восстановить ее потерянные данные.Before you resume a given secondary database, you might be able to recover lost data from it. Однако обратите внимание, что, если хотя бы одна из баз данных-получателей приостановлена, усечение журнала транзакций в данной базе данных-источнике откладывается.However, notice that transaction log truncation is delayed on a given primary database while any of its secondary databases is suspended.

Важно!

Синхронизация данных с базы данных-источника не будет выполняться, пока работа база данных-получатель не будет возобновлена.Data synchronization with the primary database will not occur until the secondary database is resumed. Сведения о возобновлении работы базы данных-получателя см. в разделе Дальнейшие действия. Основные задачи после принудительной отработки отказа далее в этой статье.For information about resuming a secondary database, see Follow Up: Essential Tasks After a Forced Failover later in this article.

Выполнение принудительной отработки отказа требуется в следующих аварийных случаях.Performing a forced failover is necessary in the following emergency situations:

  • После принудительного создания кворума в кластере WSFC (принудительный кворум) необходимо выполнить принудительную отработку отказа для каждой группы доступности (с возможной потерей данных).After forcing quorum on the WSFC cluster (forced quorum), you need to force failover each availability group (with possible data loss). Принудительная отработка отказа необходима, поскольку реальное состояние значений кластера WSFC могло быть потеряно.Forcing failover is required because the real state of the WSFC cluster values might have been lost. Однако вы можете избежать потери данных, если удалось выполнить принудительный переход на экземпляр сервера, на котором размещалась реплика, которая была первичной репликой перед принудительным созданием кворума, или на вторичную реплику, которая была синхронизирована перед принудительным созданием кворума.However, you can avoid data loss, if are able to force failover on the server instance that was hosting the replica that was the primary replica before you forced quorum or to a secondary replica that was synchronized before you forced quorum. Дополнительные сведения см. в подразделе Потенциальные методы избежания потери данных после принудительного создания кворумадалее в этом разделе.For more information, see Potential Ways to Avoid Data Loss After Quorum is Forced, later in this topic.

    Важно!

    Если кворум был восстановлен естественными средствами, а не принудительно, для реплик доступности будет выполнено обычное восстановление.If quorum is regained by natural means instead of being forced, the availability replicas will go through normal recovery. Если первичная реплика остается недоступной после восстановления кворума, вы можете выполнить запланированный переход на другой ресурс вручную на синхронизированную вторичную реплику.If the primary replica is still unavailable after quorum is regained, you can perform a planned manual failover to a synchronized secondary replica.

    Дополнительные сведения о принудительном создании кворума см. в статье Аварийное восстановление WSFC через принудительный кворум (SQL Server).For information about forcing quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server). Дополнительные сведения о причинах необходимости выполнения принудительной отработки отказа после принудительного создания кворума см. в разделе Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For information about why forcing failover is required after forcing quorum, see Failover and Failover Modes (Always On Availability Groups).

  • Если первичная реплика становится недоступной, когда кластер WSFC имеет работоспособный кворум, вы можете выполнить принудительный переход (с возможной потерей данных) на любую реплику, роль которой находится в состоянии SECONDARY или RESOLVING.If the primary replica becomes unavailable when the WSFC cluster has a healthy quorum, you can force failover (with possible data loss), to any replica whose role is in the SECONDARY or RESOLVING state. Если возможно, выполните принудительный переход на вторичную реплику с синхронной фиксацией, которая была синхронизирована в момент потери первичной реплики.If possible, force failover to a synchronous-commit secondary replica that was synchronized when the primary replica was lost.

    Совет

    Если кластер WSFC имеет работоспособный кворум, при выполнении команды принудительного перехода на синхронизированную вторичную реплику реплика фактически выполнит запланированный переход на другой ресурс вручную.When the WSFC cluster has a healthy quorum, if you issue a force failover command on a synchronized secondary replica, the replica actually performs a planned manual failover.

Примечание

Дополнительные сведения о требованиях и рекомендациях для принудительной отработки отказа, а также пример использования принудительного перехода на другой ресурс для восстановления из ситуации критического сбоя см. в подразделе Пример сценария: использование принудительной отработки отказа для восстановления после критического сбоя далее в этой статье.For more information about the prerequisites and recommendations for forcing failover and for an example scenario that uses a forced failover to recover from a catastrophic failure, see Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure, later in this topic.

ОграниченияLimitations and Restrictions

  • Единственный случай, когда нельзя выполнить принудительную отработку отказа, — кластер отказоустойчивого кластера Windows Server (WSFC) нет имеет кворума.The only time that you cannot perform a forced failover is when Windows Server Failover Clustering (WSFC) cluster lacks quorum.

  • В ходе принудительной отработки отказа группой доступности возможна потеря данных.Data loss is possible during the forced failover of an availability group. Помимо этого, если первичная реплика работает во время запуска принудительной отработки отказа, клиенты могут сохранить соединение с прежними базами данных-источниками.In addition, if the primary replica is running when you initiate a forced failover, clients might still be connected to former primary databases. Поэтому настоятельно рекомендуется выполнять принудительную отработку отказа только в том случае, если первичная реплика уже не работает, и риск потери данных является приемлемым, чтобы восстановить доступ к базам данных в группе доступности.Therefore, we strongly recommend that you force failover only if the primary replica is no longer running and if you are willing to risk losing data in order to restore access to databases in the availability group.

  • Если база данных-получатель находится в состоянии REVERTING или INITIALIZING, принудительная отработка отказа приведет к тому, что базе данных не удастся запуститься в качестве базы данных-источника.When a secondary database is in the REVERTING or INITIALIZING state, forcing failover would cause the database to fail to start as a primary database. Если база данных находилась в состоянии INTIAILIZGING, то потребуется применить отсутствующие записи журнала из резервной копии базы данных либо полностью восстановить базу данных с нуля.If the database was in the INTIAILIZGING state then you will need to apply the missing log records from a database backup or fully restore the database from scratch. Если база данных находилась в состоянии REVERTING, потребуется полностью восстановить ее из резервных копий.If the database was in the REVERTING state you will need to fully restore the database from backups.

  • Команда отработки отказа завершает работу сразу после того, как цель перехода принимает команду.A failover command returns as soon as the failover target has accepted the command. Однако восстановление базы данных происходит асинхронно после того, как группа доступности закончит отработку отказа.However, database recovery occurs asynchronously after the availability group has finished failing over.

  • Целостность данных баз данных в группе доступности во время отработки отказа может не обеспечиваться.Cross-database consistency across databases within the availability group might not be maintained on failover.

    Примечание

    Поддержка транзакций между базами данных и распределенных транзакций зависит от версий операционной системы и SQL Server.Support for cross-database and distributed transactions vary by SQL Server and operating system versions. Дополнительные сведения см. в статье Транзакции между базами данных и распределенные транзакции для групп доступности AlwaysOn и зеркального отображения базы данных (SQL Server).For more information, see Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server).

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

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

  • Не выполняйте принудительную отработку отказа, если первичная реплика все еще работает.Do not force failover while the primary replica is still running.

  • Если это возможно, выполняйте принудительный переход только на те цели перехода, базы данных-получатели которых имеют состояние NOT SYNCHRONIZED, SYNCHRONIZED или SYNCHRONIZING.If possible, force failover only to a failover target whose secondary databases are either in the NOT SYNCHRONIZED, SYNCHRONIZED, or SYNCHRONIZING state. Сведения о последствиях принудительной отработки отказа, когда база данных-получатель находится в состоянии INTIAILIZING или REVERTING, см. в разделе Ограниченияранее в этом разделе.For information about the implications of forcing failover when a secondary database is in the INTIAILIZGING or REVERTING state, see Limitations and Restrictions, earlier in this topic.

  • Как правило, задержка определенной базы данных-получателя относительно базы данных-источника должна быть одинаковой в разных вторичных репликах с асинхронной фиксацией.Typically, the latency of a given secondary database, relative to the primary database, should be similar on different asynchronous-commit secondary replicas. Тем не менее, принудительная отработка отказа может привести к значительной потере данных.However, when forcing failover, data loss can be a significant concern. В связи с этим можно потратить время на определение относительной задержки копий баз данных в разных вторичных репликах.Therefore, consider taking time to determine the relative latency of the copies of the databases on different secondary replicas. Чтобы определить, какая из копий базы данных-получателя имеет наименьшую задержку, сравните их номера LSN в конце журнала.To determine which copy of a given secondary database has the least latency, compare their end-of-log LSNs. Чем выше номер LSN конца журнала, тем меньше задержка.A higher the end-of-log LSN indicates less latency.

    Совет

    Для сравнения значений номеров LSN конца журнала подключитесь по очереди к каждой работающей вторичной реплике и определите значение end_of_log_lsn каждой локальной базы данных-получателя, отправив запрос sys.dm_hadr_database_replica_states .To compare end-of-log LSNs, connect to each online secondary replica, in turn, and query sys.dm_hadr_database_replica_states for the end_of_log_lsn value of each local secondary database. Затем сравните значения номеров LSN конца журнала для различных копий каждой базы данных.Then, compare the end-of-log LSNs of the different copies of each database. Обратите внимание: высшие значения номеров LSN для разных баз данных могут находиться на разных вторичных репликах.Note that different databases might have their highest LSNs on different secondary replicas. В этом случае выбор целевого места для отработки отказа зависит от относительной важности данных в различных базах данных.In this case, the most appropriate failover target depends on the relative importance that you place on the data in the different databases. Другими словами, следует определить, для какой базы данных нужнее всего минимизировать возможность потери данных.That is, for which of these databases would you most want to minimize possible data loss?

  • Если клиенты могут подключаться к оригинальной первичной реплике, то принудительная отработка отказа может привести к риску разбиения в работе баз данных.If clients are able to connect to the original primary, a forced failover incurs some risk of split brain behavior. Перед выполнением принудительной отработки отказа рекомендуется предотвратить возможность соединения клиентов с первичной главной репликой.Before you force failover, we strongly recommend that you prevent clients from accessing the original primary replica. В противном случае после запуска принудительной отработки отказа исходные и текущие базы данных-источники могут обновляться независимо друг от друга.Otherwise, after failover is forced, the original primary databases and the current primary databases could be updated independently of the other.

Потенциальные методы избежания потери данных после принудительного создания кворумаPotential Ways to Avoid Data Loss After Quorum is Forced

При некоторых условиях сбоя после потери кворума вы можете избежать потери данных следующим образом.Under some failure conditions after quorum is lost, you can avoid prevent data loss, as follows:

  • Если исходная первичная реплика станет доступной в сетиIf the original primary replica comes online

    Если кворум теряется и принудительное восстановление кворума WSFC восстанавливает узел кластера, на котором размещена первичная реплика группы доступности, вы можете предотвратить потерю данных для этой группы доступности.If quorum is lost and forcing WSFC quorum restores the cluster node that hosts the primary replica of an availability group, you can prevent data loss for this availability group. Подключитесь к первичной реплике и выполните принудительную отработку отказа (FAILOVER_ALLOW_DATA_LOSS).Connect to the primary replica and perform a forced failover (FAILOVER_ALLOW_DATA_LOSS). Это переведет первичную реплику в режим «в сети».This brings the primary replica back online. Поскольку выполняется принудительный переход на исходную первичную реплику, потери данных нет.Because you perform the forced failover to the original primary replica, there is no data loss.

  • Если синхронизированная вторичная реплика с синхронной фиксацией переходит в режим «в сети»If a synchronized synchronous-commit secondary replica comes online

    Если кворум потерян и принудительное восстановление кворума WSFC приводит к восстановлению узла кластера, на котором размещена синхронизированная вторичная реплика группы доступности, то потерю данных для этой группы доступности можно предотвратить.If quorum is lost and forcing WSFC quorum restores a cluster node that hosts a synchronized secondary replica for an availability group, you should be able to prevent data loss for this availability group. Если восстановленный узел был в рабочем состоянии во время потери кворума, вы можете определить, произошла ли потеря данных в указанной базе данных, с помощью запроса к столбцу is_failover_ready динамического административного представления sys.dm_hadr_database_replica_cluster_states .If the restored node was up at the time that quorum was lost, you can determine whether data loss could occur on a given database by querying the is_failover_ready column of the sys.dm_hadr_database_replica_cluster_states dynamic management view. Например, для экземпляра сервера с именем sql108w2k8r22, выполните следующий запрос:For example, for a server instance named sql108w2k8r22, issue the following query:

    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 может не отражать действительного состояния кластера в момент перехода первичной реплики в режим "вне сети".If the restored node was not up at the time quorum was lost, is_failover_ready may not reflect the cluster's actual state at the time the primary replica went offline. Поэтому значение is_failover_ready надлежащее, только если узел размещения на момент сбоя был в рабочем состоянии.Therefore, the is_failover_ready value is only good if the host node at the time of the failure. Дополнительные сведения см. в разделе "Почему принудительная отработка отказа требуется после принудительного создания кворума" статьи Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For more information, see "Why Forced Failover is Required After Forcing Quorum" in Failover and Failover Modes (Always On Availability Groups).

    Если is_failover_ready = 1, база данных помечена в кластере как синхронизированная и готовая к отработке отказа.If is_failover_ready = 1, the database is marked as synchronized in the cluster and is ready for a failover. Если is_failover_ready = 1 для всех баз данных данной вторичной реплики, вы можете выполнить принудительный переход на эту вторичную реплику (FORCE_FAILOVER_ALLOW_DATA_LOSS) без потери данных.If is_failover_ready = 1 on every database on a given secondary replica, you can perform a forced failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) without data loss on this secondary replica. Синхронизированная вторичная реплика перейдет в режим «в сети» в первичной роли как новая первичная реплика с неповрежденными данными.The synchronized secondary replica comes online in the primary role, that is, as the new primary replica, with all the data intact.

    Если is_failover_ready = 0, база данных не помечена в кластере как синхронизированная и не готова к запланированному переходу на другой ресурс вручную.If is_failover_ready = 0, the database is not marked as synchronized in the cluster and is not ready for a planned manual failover. При выполнении принудительного перехода на вторичную реплику размещения в этой базе данных будут потеряны данные.If you force failover to the host secondary replica, data will be lost on this database.

    Примечание

    При выполнении принудительного перехода на вторичную реплику объем потерянных данных зависит от того, насколько сильно цель перехода отстает от первичной реплики.When you force failover to a secondary replica, the amount of data loss will depend on how far the failover target is lagging behind the primary replica. К сожалению, если у кластера WSFC нет кворума или если был обеспечен принудительный кворум, нельзя определить объем возможной потери данных.Unfortunately, when the WSFC cluster lacks quorum or quorum has been forced, you cannot assess the amount of potential data loss. Однако после восстановления работоспособности кворума кластера WSFC можно начать отслеживать возможную потерю данных.Note, however, that once the WSFC cluster regains a healthy quorum, you could begin to track potential data loss. Дополнительные сведения см. в разделе "Отслеживание возможной потери данных" статьи Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For more information, see "Tracking Potential Data Loss" in Failover and Failover Modes (Always On Availability Groups).

PermissionsPermissions

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

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

Принудительная отработка отказа (с возможной потерей данных)To force failover (with possible data loss)

  1. В обозревателе объектов подключитесь к экземпляру сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и на которую нужно выполнить переход, и разверните дерево сервера.In Object Explorer, connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over, and expand the server tree.

  2. Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности .Expand the Always On High Availability node and the Availability Groups node.

  3. Щелкните правой кнопкой мыши группу доступности для выполнения отработки отказа и выберите команду Отработка отказа .Right-click the availability group to be failed over, and select the Failover command.

  4. Будет запущен мастер отработки отказа группой доступности.This launches the Failover Availability Group Wizard. Дополнительные сведения см. в подразделе Использование мастера отработки отказа группы доступности (среда SQL Server Management Studio).For more information, see Use the Fail Over Availability Group Wizard (SQL Server Management Studio).

  5. После принудительной отработки отказа группой доступности выполните необходимые дополнительные действия.After forcing an availability group to fail over, complete the necessary follow-up steps. Дополнительные сведения см. в разделе Дальнейшие действия. Основные задачи после принудительной отработки отказа далее в этой статье.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

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

Принудительная отработка отказа (с возможной потерей данных)To force failover (with possible data loss)

  1. Подключитесь к экземпляру сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и для которой нужно выполнить отработку отказа.Connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over.

  2. Инструкция ALTER AVAILABILITY GROUP используется следующим образом:Use the ALTER AVAILABILITY GROUP statement, as follows:

    ALTER AVAILABILITY GROUP имя_группы FORCE_FAILOVER_ALLOW_DATA_LOSSALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

    где имя_группы — это имя группы доступности.where group_name is the name of the availability group.

    В следующем примере выполняется принудительная отработка отказа группы доступности AccountsAG с переходом на локальную вторичную реплику.The following example forces the AccountsAG availability group to fail over to the local secondary replica.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
    
  3. После принудительной отработки отказа группой доступности выполните необходимые дополнительные действия.After forcing an availability group to fail over, complete the necessary follow-up steps. Дополнительные сведения см. в разделе Дальнейшие действия. Основные задачи после принудительной отработки отказа далее в этой статье.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

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

Принудительная отработка отказа (с возможной потерей данных)To force failover (with possible data loss)

  1. Перейдите в каталог (cd) экземпляра сервера, на котором размещена реплика группы доступности, роль которой находится в состоянии SECONDARY или RESOLVING и для которой нужно выполнить отработку отказа.Change directory (cd) to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over.

  2. Используйте командлет Switch-SqlAvailabilityGroup с параметром AllowDataLoss в одной из следующих форм:Use the Switch-SqlAvailabilityGroup cmdlet with the AllowDataLoss parameter in one of the following forms:

    • -AllowDataLoss-AllowDataLoss

      По умолчанию применение параметра -AllowDataLoss приводит к тому, что Switch-SqlAvailabilityGroup подскажет, что принудительная отработка отказа может вызвать потерю незавершенных транзакций, и запросит подтверждение.By default -AllowDataLoss parameter causes Switch-SqlAvailabilityGroup to prompt you to remind you that forcing failover might result in the loss of uncommitted transactions and to request confirmation. Чтобы продолжить, введите букву Y; чтобы отменить операцию, введите букву N.To continue, enter Y; to cancel the operation, enter N.

      В следующем примере выполняется принудительная отработка отказа (с возможной потерей данных) группой доступности MyAg на вторичную реплику на экземпляре сервера с именем SecondaryServer\InstanceName.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the secondary replica on the server instance named SecondaryServer\InstanceName. Будет предложено подтвердить эту операцию.You will be prompted to confirm this operation.

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

      Чтобы инициировать принудительную отработку отказа без подтверждения, укажите оба параметра, -AllowDataLoss и -Force .To initiate a forced failover without confirmation, specify both the -AllowDataLoss and -Force parameters. Это полезно, если нужно включить команду в скрипт и запустить ее без взаимодействия с пользователем.This is useful if you want to include the command in a script and run it without user interaction. Однако пользуйтесь параметром -Force осмотрительно, так как принудительная отработка отказа может привести к потере данных в базах данных, принадлежащих группе доступности.However, use the -Force option with caution, because a forced failover might result in the loss of data from databases participating the availability group.

      В следующем примере выполняется принудительная отработка отказа (с возможной потерей данных) группой доступности MyAg на экземпляр сервера с именем SecondaryServer\InstanceName.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the server instance named SecondaryServer\InstanceName. Параметр -Force подавляет выдачу подтверждения этой операции.The -Force option suppresses confirmation of this operation.

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

    Примечание

    Чтобы просмотреть синтаксис командлета, воспользуйтесь командлетом Get-Help в среде PowerShell SQL ServerSQL Server .To view the syntax of a cmdlet, use the Get-Help cmdlet in the SQL ServerSQL Server PowerShell environment. Дополнительные сведения см. в разделе Get Help SQL Server PowerShell.For more information, see Get Help SQL Server PowerShell.

  3. После принудительной отработки отказа группой доступности выполните необходимые дополнительные действия.After forcing an availability group to fail over, complete the necessary follow-up steps. Дополнительные сведения см. в разделе Дальнейшие действия. Основные задачи после принудительной отработки отказа далее в этой статье.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

Настройка и использование поставщика SQL Server PowerShellTo set up and use the SQL Server PowerShell provider

Дальнейшие действия. Основные задачи после принудительной отработки отказаFollow Up: Essential Tasks After a Forced Failover

  1. После принудительной отработки отказа вторичная реплика, на которую перешла группа доступности, становится новой первичной репликой.After a forced failover, the secondary replica to which you failed over becomes the new primary replica. Однако, чтобы сделать эту реплику доступности доступной клиентам, может потребоваться повторная настройка WSFC-кворума или регулировка конфигурации режима доступности для группы доступности.However, to make that availability replica accessible to clients, you might need to reconfigure the WSFC quorum or adjust the availability-mode configuration of the availability group, as follows:

    • Если отработка отказа выполнена за пределами задан автоматический переход на другой ресурсautomatic failover set Отрегулируйте голоса кворума WSFC-узлов так, чтобы они соответствовали новой конфигурации группы доступности.If you failed over outside of the задан автоматический переход на другой ресурсautomatic failover set: Adjust the quorum votes of the WSFC nodes to reflect your new availability group configuration. Если WSFC-узел, на котором размещена целевая вторичная реплика, не имеет голоса WSFC-кворума, может потребоваться получить WSFC-кворум принудительно.If the WSFC node that hosts the target secondary replica does not have a WSFC quorum vote, you might need to force WSFC quorum.

      Примечание

      задан автоматический переход на другой ресурсautomatic failover set существует, только если две реплики доступности (включая прежнюю первичную реплику) настроены на режим синхронной фиксации с автоматическим переходом на другой ресурс.An задан автоматический переход на другой ресурсautomatic failover set exists only if two availability replicas (including the previous primary replica) are configured for synchronous-commit mode with automatic failover.

      Настройка голосов кворумаTo adjust quorum votes

    • Если отработка отказа выполнена за пределами задана отработка отказа синхронной фиксацииsynchronous-commit failover set Рекомендуется регулировка режима доступности и отработки отказа на новой первичной реплике и на оставшихся вторичных репликах так, чтобы они соответствовали нужной конфигурации синхронной фиксации и автоматического перехода на другой ресурс.If you failed over outside of the задана отработка отказа синхронной фиксацииsynchronous-commit failover set: We recommend that you consider adjusting the availability mode and failover mode on the new primary replica and on remaining secondary replicas to reflect your desired synchronous-commit and automatic failover configuration.

      Примечание

      задана отработка отказа синхронной фиксацииsynchronous-commit failover set существует только в том случае, если текущая первичная реплика настроена для работы в режиме синхронной фиксации.A задана отработка отказа синхронной фиксацииsynchronous-commit failover set exists only if the current primary replica is configured for synchronous-commit mode.

      Изменение режима доступности и режима отработки отказаTo change the availability mode and failover mode

  2. После принудительной отработки отказа приостанавливаются все базы данных-получатели.After a forced failover, all secondary databases are suspended. Это относится к бывшим базам данных-источникам, для которых бывшая первичная реплика вновь переходит в режим «в сети» и обнаруживает, что отныне является вторичной репликой.This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. Необходимо вручную возобновить работу каждой приостановленной базы данных во вторичной реплике.You must manually resume each suspended database individually on each secondary replica.

    При возобновлении база данных-получатель инициирует синхронизацию данных с соответствующей базой данных-источником.When a secondary database is resumed, it initiates data synchronization with the corresponding primary database. База данных-получатель откатывает все записи журнала, не зафиксированные в новой базе данных-источнике.The secondary database rolls back any log records that were never committed on the new primary database. Поэтому во избежание потери данных в базах данных-источниках после отработки отказа следует попытаться создать моментальный снимок приостановленных баз данных в одной из баз данных-получателей с синхронной фиксацией.Therefore, if you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one of the synchronous-commit secondary databases.

    Важно!

    Если хотя бы одна из баз данных-получателей приостановлена, усечение журнала транзакций в базе данных-источнике откладывается.Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. Кроме того, во время приостановки любой локальной базы данных невозможен переход состояния вторичной реплики с синхронной фиксацией в HEALTHY.Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

    Создание моментального снимка базы данныхTo create a database snapshot

    Возобновление базы данных доступностиTo resume an availability database

    Внимание!

    После восстановления всех баз данных-получателей перед повторной попыткой отработки отказа этой группы необходимо дождаться, пока все базы данных-получатели на следующей резервной группе будут переведены в состояние SYNCHRONIZING.After resuming all the secondary databases, before attempting to fail over the group again, wait for every secondary database on the next failover target to enter the SYNCHRONIZING state. Если какая-либо база данных еще не находится в состоянии SYNCHRONIZING, эта база данных не сможет выйти в сеть в качестве базы данных-источника, а для восстановления синхронизации данных с ней может потребоваться восстановление журналов транзакций, полное резервное восстановление базы данных или откат к прежней первичной реплике.If any database is not yet SYNCHRONIZING, that database will be prevented from coming online as a primary database, and re-establishing data synchronization for the database might require restoring transaction logs, restoring a full database backup, or failing over back to the previous primary replica.

  3. Если реплика доступности, которая дала сбой, не вернется на место реплики доступности или вернется слишком поздно и усечение журнала транзакций для новой базы данных-источника будет задержано, рекомендуется удалить из группы доступности реплику, давшую сбой, чтобы избежать исчерпания места на диске для файлов журнала.If an availability replica that failed will not be returning to the availability replica or will return too late for you to delay transaction log truncation on the new primary database, consider removing the failed replica from the availability group to avoid running out of disk space for your log files.

    Удаление вторичной репликиTo remove a secondary replica

  4. Если необходима принудительная отработка отказа с одной или несколькими дополнительными принудительными отработками отказа, выполняйте резервное копирование журналов после каждой дополнительной принудительной отработки отказа.If you follow a forced failover with one or more additional forced failovers, perform a log backup after each additional forced failover in the series. О том, по каким причинам это необходимо, см. пункт "Риск использования принудительной отработки отказа" в разделе "Принудительный переход на другой ресурс вручную (с возможной потерей данных)" статьи Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For information about the reason for this, see "Risks of Forcing Failover" in the "Forced Manual Failover (with Possible Data Loss)" section of Failover and Failover Modes (Always On Availability Groups).

    Создание резервной копии журналаTo perform a log backup

Пример сценария. Использование принудительной отработки отказа для восстановления после разрушительного сбояExample Scenario: Using a Forced Failover to Recover from a Catastrophic Failure

В случае отказа первичной реплики при отсутствии синхронизированной вторичной реплики может оказаться целесообразной принудительная отработка отказа группы доступности.If the primary replica fails and no synchronized secondary replica is available, forcing the availability group to fail over might be an appropriate response. Целесообразность принудительной отработки отказа зависит от следующего: 1) ожидается ли остановка первичной реплики на время, превышающее допустимое время простоя в соглашении об уровне обслуживания (SLA), и 2) есть ли смысл рисковать возможной потерей данных для обеспечения быстрого доступа к базе данных-источнику.The appropriateness of forcing a failover depends on: (1) whether you expect the primary replica to be offline for longer than your service level agreement (SLA) tolerates, and (2) whether you are willing to risk potential data loss in order to make primary databases available quickly. Если принято решение о принудительной отработке отказа группы доступности, сама принудительная отработка отказа является лишь одним этапом многошагового процесса.If you decide that an availability group requires a forced failover, the actual forced failover is but one step of a multi-step process.

Для иллюстрации шагов, необходимых для восстановления после разрушительного сбоя с помощью принудительной отработки отказа, в данном разделе представлен один из возможных сценариев восстановления.To illustrate the steps that are required to use a forced failover to recover from a catastrophic failure, this topic presents one possible disaster recovery scenario. Данный сценарий подразумевает наличие группы доступности, изначальная топология которой состоит из основного центра обработки данных, где размещены три реплики доступности с синхронной фиксацией (в том числе первичная реплика), и удаленного центра обработки данных, где размещены две вторичные реплики с асинхронной фиксацией.The example scenario considers an availability group whose original topology consists of a main data center that hosts three synchronous-commit availability replicas, including the primary replica, and a remote data center that hosts two asynchronous-commit secondary replicas. На следующем рисунке изображена изначальная топология группы доступности в данном примере:The following figure illustrates the original topology of this example availability group. Группа доступности размещается в кластере WSFC со несколькими подсетями; три узла находятся в основном центре обработки данных (Node 01, Node 02и Node 03), и два узла в удаленном центре обработки данных (Node 04 и Node 05).The availability group is hosted by a multi-subnet WSFC cluster with three nodes in the main data center (Node 01, Node 02, and Node 03) and two nodes in a remote data center (Node 04 and Node 05).

Изначальная топология группы доступностиOriginal topology of availability group

Основной центр обработки данных неожиданно выключается.The main data center shuts down unexpectedly. Находящиеся там три реплики доступности переходят в состояние «вне сети», соответствующие базы данных становятся недоступны.Its three availability replicas to go offline, and their databases become unavailable. Влияние данного сбоя на топологию группы доступности показано на следующем рисунке.The following figure illustrates the impact of this failure on the topology of the availability group.

Топология после сбоя основного центра обработки данныхTopology after failure of main data center

Администратор баз данных (DBA) принимает решение о принудительной отработке отказа группы доступности с использованием одной из удаленных вторичных реплик с асинхронной фиксацией.The database administrator (DBA) determines that the best possible response is to force failover of the availability group to one of the remote, asynchronous-commit secondary replicas. В данном примере приведены типичные шаги для принудительной отработки отказа с использованием удаленной реплики и последующего восстановления изначальной топологии группы доступности.This example illustrates the typical steps involved when you force failover of the availability group to a remote replica and, eventually, return the availability group to its original topology.

Представленные ниже ответные действия после сбоя состоят из следующих двух этапов:The failure-response presented here consists of the following two phases:

Responding to the Catastrophic Failure of the Main Data CenterResponding to the Catastrophic Failure of the Main Data Center

На следующем рисунке показана последовательность действий, осуществляемых в удаленном центре обработки данных после разрушительного сбоя в основном центре обработки данных.The following figure illustrates the series of actions performed at the remote data center in response a catastrophic failure at the main data center.

Действия по обработке сбоя в основном центре обработки данныхSteps for responding to failure of main data center

На данном рисунке указаны следующие шаги:The steps in this figure indicate the following steps:

ШагStep ДействиеAction СсылкиLinks
1.1. Администратор баз данных (DBA) или администратор локальной сети убеждается, что в кластере соблюдается кворум.The DBA or network administrator ensures that the WSFC cluster has a healthy quorum. В данном примере необходим принудительный кворум.In this example, quorum needs to be forced. Режим кворума и участвующая в голосовании конфигурация WSFC (SQL Server)WSFC Quorum Modes and Voting Configuration (SQL Server)

Аварийное восстановление WSFC через принудительный кворум (SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)
2.2. DBA подключается к экземпляру сервера с наименьшей задержкой ( Node 04) и осуществляет принудительный переход на другой ресурс вручную.The DBA connects to the server instance with the least latency (on Node 04) and performs a forced manual failover. В результате принудительной отработки отказа эта вторичная реплика становится первичной, а базы данных-получатели в оставшейся вторичной реплике ( Node 05) приостанавливаются.The forced failover transitions this secondary replica to the primary role and suspends the secondary databases on the remaining secondary replica (on Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) (Запрос столбца sys.dm_hadr_database_replica_states .sys.dm_hadr_database_replica_states (Transact-SQL) (Query the end_of_log_lsn column. Дополнительные сведения см. в подразделе Рекомендацииранее в этом разделе.)For more information, see Recommendations, earlier in this topic.)
3.3. DBA вручную возобновляет работу каждой базы данных-получателя в оставшейся вторичной реплике.The DBA manually resumes each of the secondary databases on the remaining secondary replica. Возобновление базы данных доступности (SQL Server)Resume an Availability Database (SQL Server)

Восстановление изначальной топологии группы доступностиReturning the Availability Group to its Original Topology

На следующем рисунке показана последовательность действий для восстановления изначальной топологии группы доступности после возобновления работы основного центра обработки данных и восстановления связи узлов WSFC с кластером WSFC.The following figure illustrates the series of actions that return the availability group to its original topology after the main data center comes back online and the WSFC nodes re-establish communication with the WSFC cluster.

Важно!

Если ранее в кластере WSFC был обеспечен принудительный кворум, вновь запускающиеся узлы могут сформировать новый кворум в случае одновременного соблюдения следующих двух условий: (a) отсутствует сетевая связь между любыми двумя узлами, участвовавшими в принудительном кворуме, и (б) вновь запускающиеся узлы составляют большинство из всех узлов кластера.If the WSFC cluster quorum has been forced, as the offline nodes restart they could form a new quorum if the following conditions both exist: (a) there is no network connectivity between any of the nodes in the forced-quorum set, and (b) the restarting nodes are the majority of the cluster nodes. Это приведет к состоянию «двух голов», при котором в группе доступности появятся две независимые первичные реплики, каждая в своем центре обработки данных.This would result in a "split brain" condition in which the availability group would possess two independent primary replicas, one at each data center. Прежде чем создавать кворумное меньшинство с помощью принудительного кворума, см. статью Аварийное восстановление WSFC через принудительный кворум (SQL Server).Before forcing quorum to create a minority quorum set, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

Действия по восстановлению группы к ее изначальной топологииSteps to return the group to its original topology

На данном рисунке указаны следующие шаги:The steps in this figure indicate the following steps:

ШагStep СсылкиLinks
1.1. Узлы в основном центре обработки данных вновь запускаются и восстанавливают связь с кластером WSFC.The nodes in the main data center come back online and re-establish communication with the WSFC cluster. Их реплики доступности переходят в режим «в сети» в качестве вторичных реплик с приостановленными базами данных; DBA предстоит вручную возобновить работу каждой из этих баз данных.Their availability replicas come online as secondary replicas with suspended databases, and the DBA will need to manually resume each of these databases soon. Возобновление базы данных доступности (SQL Server)Resume an Availability Database (SQL Server)

Совет. Во избежание потери данных в базах данных, ставших источниками после отработки отказа, следует попытаться создать моментальный снимок приостановленных баз данных в одной из баз данных-получателей с синхронной фиксацией.Tip: If you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one the synchronous-commit secondary database. Следует помнить, что если хотя бы одна из баз данных-получателей приостановлена, усечение журнала транзакций в базе данных-источнике откладывается.Keep in mind that the transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. Кроме того, во время приостановки любой локальной базы данных невозможен переход состояния вторичной реплики с синхронной фиксацией в HEALTHY.Also the synchronization health of the synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.
2.2. После возобновления работы баз данных DBA временно изменяет режим фиксации первичной реплики на синхронный.Once the databases are resumed, the DBA changes the new primary replica to synchronous-commit mode temporarily. Данное действие состоит из следующих шагов:This involves two steps:

1) Изменение режима фиксации одной из реплик доступности в режиме "вне сети" на асинхронный.1) Change one offline availability replica to asynchronous-commit mode.

2) Изменение режима фиксации новой первичной реплики на синхронный.2) Change the new primary replica to synchronous-commit mode. Примечание. Данное действие позволяет базам данных-получателям с синхронной фиксацией перейти в состояние SYNCHRONIZED.Note: This step enables resumed synchronous-commit secondary databases to become SYNCHRONIZED.
Смена режима доступности для реплики доступности (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)
3.3. После перехода вторичной реплики с синхронной фиксацией на Node 03 (изначальная первичная реплика) в состояние HEALTHY, DBA вручную осуществляет запланированную отработку отказа с использованием этой реплики, чтобы вновь сделать ее первичной.Once the synchronous-commit secondary replica on Node 03 (the original primary replica) enters the HEALTHY synchronization state, the DBA performs a planned manual failover to that replica, to make it the primary replica again. Реплика на узле Node 04 вновь становится вторичной.The replica on Node 04 returns to being a secondary replica. sys.dm_hadr_database_replica_states (Transact-SQL)sys.dm_hadr_database_replica_states (Transact-SQL)

Использование политик AlwaysOn для определения работоспособности группы доступности (SQL Server)Use Always On Policies to View the Health of an Availability Group (SQL Server)

Выполнение запланированного перехода на другой ресурс вручную для группы доступности (SQL Server)Perform a Planned Manual Failover of an Availability Group (SQL Server)
4.4. DBA подключается к новой первичной реплике и делает следующее:The DBA connects to the new primary replica and:

1) Изменяет режим фиксации бывшей первичной реплики (в удаленном центре обработки данных) на асинхронный.1) Changes the former primary replica (in the remote center) back to asynchronous-commit mode.

2) Изменяет режим фиксации вторичной реплики в основном центре обработки данных обратно на синхронный.2) Changes the asynchronous-commit secondary replica in the main data center back to synchronous-commit mode.
Смена режима доступности для реплики доступности (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)

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

Настройка голосов кворумаTo adjust quorum votes

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

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

См. такжеRelated Content

См. также:See Also

Обзор групп доступности AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Режимы доступности (группы доступности AlwaysOn) Availability Modes (Always On Availability Groups)
Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Сведения о доступе клиентского подключения к репликам доступности (SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
Отслеживание групп доступности (SQL Server) Monitoring of Availability Groups (SQL Server)
Отказоустойчивая кластеризация Windows Server (WSFC) с SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server