Выполнение планового перехода на другой ресурс вручную для группы доступности Always On (SQL Server)Perform a planned manual failover of an Always On availability group (SQL Server)

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

В этом разделе описывается выполнение перехода на другой ресурс вручную без потери данных (запланированный переход на другой ресурс вручную) в группе доступности AlwaysOn с помощью среды SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL или PowerShell в SQL Server 2017SQL Server 2017.This topic describes how to perform a manual failover without data loss (a planned manual failover) on an AlwaysOn availability group by using SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL, or PowerShell in SQL Server 2017SQL Server 2017. Группа доступности выполняет переход на другой ресурс на уровне реплики доступности.An availability group fails over at the level of an availability replica. Запланированный переход на другой ресурс вручную, как и любая другая отработка отказа для группы доступности AlwaysOn, переводит вторичную реплику на основную роль.A planned manual failover, like any AlwaysOn availability group failover, transitions a secondary replica to primary role. При этом бывшая первичная реплика принимает роль вторичной.Concurrently, the failover transitions the former primary replica to the secondary role.

Этот переход поддерживается, только если первичная и целевая вторичная реплики работают в режиме синхронной фиксации и в текущий момент синхронизированы.A planned manual failover is supported only when the primary replica and the target secondary replica are running in synchronous-commit mode and are currently synchronized. При запланированном переходе на другой ресурс вручную сохраняются все данные в базах данных-получателях, подключенных к группе доступности на целевой вторичной реплике.A planned manual failover preserves all the data in the secondary databases that are joined to the availability group on the target secondary replica. После перевода бывшей первичной реплики на роль вторичной ее базы данных становятся базами данных — получателями.After the former primary replica transitions to the secondary role, its databases become secondary databases. Затем они начинают синхронизироваться с новыми базами данных — источниками.Then they begin to synchronize with the new primary databases. После того как они все перейдут в состояние SYNCHRONIZED, новая вторичная реплика может служить целью будущей запланированного перехода на другой ресурс вручную.After they all transition into the SYNCHRONIZED state, the new secondary replica becomes eligible to serve as the target of a future planned manual failover.

Примечание

Если и первичная, и вторичная реплики настроены на автоматический переход на другой ресурс, то вторичная реплика может служить целевой и для этого перехода после синхронизации.If the secondary and primary replicas are both configured for automatic failover mode, after the secondary replica is synchronized, it also can serve as the target for an automatic failover. Дополнительные сведения см. в разделе Режимы доступности (Группы доступности AlwaysOn).For more information, see Availability modes (AlwaysOn availability groups).

Перед началомBefore you begin

Важно!

Существуют определенные процедуры по отработке отказа группы доступности для чтения и масштабирования без диспетчера кластеров.There are specific procedures to fail over a read-scale availability group with no cluster manager. Если в группе доступности задан параметр CLUSTER_TYPE = NONE (тип кластера — отсутствует), следуйте процедурам, описанным в разделе Отработка отказа первичной реплики в группе доступности для чтения и масштабирования.When an availability group has CLUSTER_TYPE = NONE, follow the procedures under Fail over the primary replica on a read-scale availability group.

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

Требования и ограниченияPrerequisites and restrictions

  • Первичная и целевая вторичная реплики должны работать в режиме доступности с синхронной фиксацией.Both the target secondary replica and the primary replica must be running in synchronous-commit availability mode.

  • Целевая вторичная реплика сейчас должна быть синхронизирована с первичной репликой.Currently, the target secondary replica must be synchronized with the primary replica. Все базы данных — получатели в этой вторичной реплике должны быть подключены к группе доступности.All the secondary databases on this secondary replica must be joined to the availability group. Они также должны быть синхронизированы с соответствующими базами данных — источниками (то есть локальные базы данных — получатели должны быть в состоянии SYNCHRONIZED).They also must be synchronized with their corresponding primary databases (that is, the local secondary databases must be SYNCHRONIZED).

    Совет

    Чтобы определить готовность вторичной реплики к отработке отказа, запросите столбец is_failover_ready в динамическом административном представлении sys.dm_hadr_database_cluster_states.To determine the failover readiness of a secondary replica, query the is_failover_ready column in the sys.dm_hadr_database_cluster_states dynamic management view. Либо проверьте значение столбца Готовность к отработке отказа в панели мониторинга группы AlwaysOn.Or you can look at the Failover Readiness column of the AlwaysOn group dashboard.

  • Эта задача поддерживается только в целевой вторичной реплике.This task is supported only on the target secondary replica. Необходимо подключиться к экземпляру сервера, на котором размещается целевая вторичная реплика.You must be connected to the server instance that hosts the target secondary replica.

безопасностьSecurity

PermissionsPermissions

Группе доступности необходимо предоставить разрешение ALTER AVAILABILITY GROUP.The ALTER AVAILABILITY GROUP permission is required on the availability group. Также необходимо разрешение CONTROL AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP или CONTROL SERVER.The CONTROL AVAILABILITY GROUP permission, the ALTER ANY AVAILABILITY GROUP permission, or the CONTROL SERVER permission also is required.

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

Чтобы выполнить отработку отказа для группы доступности вручную выполните следующее.To manually fail over an availability group:

  1. В обозревателе объектов подключитесь к экземпляру сервера, где размещена вторичная реплика группы доступности, для которой требуется отработка отказа.In Object Explorer, connect to a server instance that hosts a secondary replica of the availability group that needs to be failed over. Разверните дерево сервера.Expand the server tree.

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

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

  4. Запустится мастер отработки отказа группы доступности.The Failover Availability Group wizard starts. Дополнительные сведения: Использование мастера отработки отказа группы доступности (SQL Server Management Studio).For more information, see Use the Failover Availability Group wizard (SQL Server Management Studio).

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

Чтобы выполнить отработку отказа для группы доступности вручную выполните следующее.To manually fail over an availability group:

  1. Подключитесь к экземпляру сервера, на котором находится целевая вторичная реплика.Connect to the server instance that hosts the target secondary replica.

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

    ALTER AVAILABILITY GROUP имя_группы FAILOVERALTER AVAILABILITY GROUP group_name FAILOVER

    В этой инструкции имя_группы — это имя группы доступности.In the statement, group_name is the name of the availability group.

    В следующем примере выполняется ручная отработка отказа группы доступности MyAg на подключенную вторичную реплику.The following example manually fails over the MyAg availability group to the connected secondary replica:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;  
    

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

Чтобы выполнить отработку отказа для группы доступности вручную выполните следующее.To manually fail over an availability group:

  1. Перейдите в каталог (cd) экземпляра сервера, на котором размещена целевая вторичная реплика.Change the directory (cd) to the server instance that hosts the target secondary replica.

  2. Используйте командлет Switch-SqlAvailabilityGroup .Use the Switch-SqlAvailabilityGroup cmdlet.

    Примечание

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

    В следующем примере выполняется ручная отработка отказа группы доступности MyAg на вторичную реплику по указанному пути:The following example manually fails over the MyAg availability group to the secondary replica with the specified path:

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

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

Дальнейшие действия. После отработки отказа группы доступности вручнуюFollow up: After you manually fail over an availability group

Если отработка отказа была выполнена на ресурс, не входящий в задан автоматический переход на другой ресурсautomatic failover set группы доступности, перенастройте голоса кворума узлов отказоустойчивой кластеризации Windows Server, чтобы отразить новую конфигурацию группы доступности.If you failed over outside the задан автоматический переход на другой ресурсautomatic failover set of the availability group, adjust the quorum votes of the Windows Server failover clustering nodes to reflect your new availability group configuration. Дополнительные сведения: Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server.For more information, see Windows Server failover clustering (WSFC) with SQL Server.

Отработка отказа первичной реплики в группе доступности для чтения и масштабированияFail over the primary replica on a read-scale availability group

Каждая группа доступности имеет только одну первичную реплику.Each availability group has only one primary replica. Первичная реплика позволяет выполнять операции чтения и записи.The primary replica allows reads and writes. Чтобы изменить первичную реплику, можно выполнить переход на другой ресурс.To change which replica is primary, you can fail over. В группе доступности для обеспечения высокой доступности диспетчер кластеров автоматизирует процесс перехода на другой ресурс.In an availability group for high availability, the cluster manager automates the failover process. В группе доступности с типом кластера NONE принудительная отработка отказа выполняется вручную.In an availability group with cluster type NONE, the failover process is manual.

Существует два способа отработки отказа первичной реплики в группе доступности с типом кластера NONE.There are two ways to fail over the primary replica in an availability group with cluster type NONE:

  • Принудительный переход на другой ресурс вручную с потерей данныхForced manual failover with data loss
  • Переход на другой ресурс вручную без потери данныхManual failover without data loss

Принудительный переход на другой ресурс вручную с потерей данныхForced manual failover with data loss

Это метод можно использовать, если первичная реплика недоступна и не может быть восстановлена.Use this method when the primary replica isn't available and can't be recovered.

Для принудительной отработки отказа с потерей данных подключитесь к экземпляру SQL Server, в котором размещена целевая вторичная реплика, и выполните следующие команды:To force failover with data loss, connect to the SQL Server instance that hosts the target secondary replica and then run the following command:

ALTER AVAILABILITY GROUP [ag1] FORCE_FAILOVER_ALLOW_DATA_LOSS;

При восстановлении предыдущей первичной реплики требуется первичная роль.When the previous primary replica recovers, it will also assume the primary role. Чтобы убедиться, что предыдущая первичная реплика переходит на вторичную роль, выполните на ней приведенную ниже команду.To ensure that the previous primary replica transitions into a secondary role run the following command on the previous primary replica.

ALTER AVAILABILITY GROUP [ag1]  SET (ROLE = SECONDARY);

Переход на другой ресурс вручную без потери данныхManual failover without data loss

Это метод можно использовать, если первичная реплика доступна, но необходимо временно или навсегда изменить конфигурацию и изменить экземпляр SQL Server, на котором размещена первичная реплика.Use this method when the primary replica is available, but you need to temporarily or permanently change the configuration and change the SQL Server instance that hosts the primary replica. Чтобы избежать возможной потери данных, перед началом ручной отработки отказа убедитесь, что целевая вторичная реплика находится в актуальном состоянии.To avoid potential data loss, before you issue the manual failover, ensure that the target secondary replica is up to date.

Чтобы перейти на другой ресурс вручную без потери данных, выполните следующие действия.To manually fail over without data loss:

  1. Выполните для целевой вторичной реплики SYNCHRONOUS_COMMIT.Make the target secondary replica SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [ag1] 
         MODIFY REPLICA ON N'<node2>' 
         WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
    
  2. Чтобы определить, что активные транзакции фиксируются в первичной реплике и по меньшей мере в одной синхронной вторичной реплике, выполните следующий запрос:To identify that active transactions are committed to the primary replica and at least one synchronous secondary replica, run the following query:

    SELECT ag.name, 
       drs.database_id, 
       drs.group_id, 
       drs.replica_id, 
       drs.synchronization_state_desc, 
       ag.sequence_number
    FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
    WHERE drs.group_id = ag.group_id; 
    

    Вторичная реплика синхронизируется, если synchronization_state_desc имеет значение SYNCHRONIZED.The secondary replica is synchronized when synchronization_state_desc is SYNCHRONIZED.

  3. Обновите REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT до 1.Update REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT to 1.

    Следующий скрипт задает для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 в группе доступности ag1.The following script sets REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT to 1 on an availability group named ag1. Перед запуском скрипта замените ag1 именем группы доступности.Before you run the following script, replace ag1 with the name of your availability group:

    ALTER AVAILABILITY GROUP [ag1] 
         SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
    

    Этот параметр означает, что все активные транзакции фиксируются на первичной реплике и по меньшей мере на одной синхронной вторичной реплике.This setting ensures that every active transaction is committed to the primary replica and at least one synchronous secondary replica.

  4. Понизьте роль первичной реплики до вторичной.Demote the primary replica to a secondary replica. После понижения роли первичная реплика становится доступной только для чтения.After the primary replica is demoted, it's read-only. Чтобы изменить ее роль на SECONDARY, выполните на экземпляре SQL Server, где размещена первичная реплика, следующую команду:To update the role to SECONDARY, run the following command on the SQL Server instance that hosts the primary replica:

    ALTER AVAILABILITY GROUP [ag1] 
         SET (ROLE = SECONDARY); 
    
  5. Повысьте уровень целевой вторичной реплики до первичной.Promote the target secondary replica to primary.

    ALTER AVAILABILITY GROUP ag1 FORCE_FAILOVER_ALLOW_DATA_LOSS; 
    

    Примечание

    Для удаления группы доступности используйте DROP AVAILABILITY GROUP.To delete an availability group, use DROP AVAILABILITY GROUP. Для группы доступности, созданной с типом кластера NONE или EXTERNAL, выполните команду на всех репликах, входящих в группу доступности.For an availability group that's created with cluster type NONE or EXTERNAL, execute the command on all replicas that are part of the availability group.

См. также разделSee also