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

Отработка отказа — Управляемый экземпляр SQL Azure

  • Статья

Область применения: Управляемый экземпляр SQL Azure

В этой статье описывается, как выполнить отработку отказа базы данных, связанной между SQL Server и Управляемый экземпляр SQL Azure с помощью SQL Server Management Studio (SSMS) или PowerShell для аварийного восстановления или миграции.

Необходимые компоненты

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

Остановка рабочей нагрузки

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

Отработка отказа базы данных

Вы можете выполнить отработку отказа связанной базы данных с помощью Transact-SQL (T-SQL), SQL Server Management Studio или PowerShell.

Вы можете выполнить отработку отказа с помощью Transact-SQL, начиная с SQL Server 2022 CU13 (KB5036432).

Чтобы выполнить плановая отработка отказа для ссылки, используйте следующую команду T-SQL в первичной реплике:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Для выполнения принудительной отработки отказа используйте следующую команду T-SQL на вторичной реплике:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Просмотр базы данных после отработки отказа

Для SQL Server 2022, если вы решили сохранить ссылку, можно проверить, существует ли распределенная группа доступности в обозреватель объектов в SQL Server Management Studio.

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

Очистка после отработки отказа

Если после успешной отработки отказа не выбрана ссылка, отработка отказа с помощью SQL Server 2022 не прерывает эту ссылку. Вы можете сохранить ссылку после отработки отказа, которая оставляет группу доступности и активна распределенная группа доступности. Дополнительные действия не требуются.

Удаление ссылки удаляет только распределенную группу доступности и оставляет группу доступности активной. Вы можете сохранить группу доступности или удалить ее.

Если вы решите удалить группу доступности, замените следующее значение и запустите пример кода T-SQL:

  • <AGName> с именем группы доступности на SQL Server (используется для создания ссылки).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Несогласованное состояние после принудительной отработки отказа

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

Во-первых, убедитесь, что вы находитесь в сценарии разделения мозга. Это можно сделать с помощью SQL Server Management Studio (SSMS) или Transact-SQL (T-SQL).

Подключитесь как к управляемому экземпляру SQL Server, так и к управляемому экземпляру SQL в SSMS, а затем в обозреватель объектов разверните реплики доступности в узле группы доступности AlwaysOn. Если две разные реплики перечислены как основное, вы находитесь в сценарии разделения мозга.

Кроме того, можно запустить следующий скрипт T-SQL как в SQL Server, так и в Управляемый экземпляр SQL, чтобы проверить роль реплик:

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

Если оба экземпляра перечисляют другую первичную роль в столбце роли "Ссылка", вы находитесь в сценарии разделения мозга.

Чтобы устранить разделенное состояние мозга, сначала создайте резервную копию на любой реплике, которая была исходной первичной. Если исходный источник был SQL Server, создайте резервную копию журнала хвоста. Если исходный основной объект был Управляемый экземпляр SQL, выполните резервную копию только для копирования. После завершения резервного копирования установите распределенную группу доступности на вторичную роль для реплики, которая использовалась для исходной первичной, но теперь будет новой вторичной.

Например, в случае истинной аварии при условии, что вы принудили отработку отказа рабочей нагрузки SQL Server на Управляемый экземпляр SQL Azure, и планируете продолжить выполнение рабочей нагрузки на Управляемый экземпляр SQL, создайте резервную копию журналов хвоста в SQL Server, а затем задайте распределенную группу доступности вторичной роли в SQL Server, например следующий пример:

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO

Затем выполните плановую отработку отказа вручную из Управляемый экземпляр SQL в SQL Server с помощью ссылки, например в следующем примере:

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO

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

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

Дополнительные сведения о ссылке:

Для других сценариев репликации и миграции рекомендуется: