Механизм отказоустойчивости — Azure SQL Managed Instance

Применимо к:Azure SQL Managed Instance

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

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

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

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

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

Проверка задержки репликации

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

Используйте следующий запрос T-SQL в SQL Server и SQL Managed Instance для отслеживания задержки репликации между репликами:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

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

Переключение на резервную базу данных

Вы можете выполнить переключение связанной базы данных с помощью 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

Внимание

После выполнения планового переключения режим репликации устанавливается на асинхронный.

Переключение для нескольких баз данных

Если вы планируете выполнить отработку отказа нескольких баз данных из экземпляров на одном сервере для оптимальной производительности и прогнозируемости, выполните отработку отказа 8 баз данных на один экземпляр одновременно. Например, если у вас есть 10 экземпляров с 32 связанными базами данных в каждом, переключайте на резерв по 8 баз данных за раз из каждого экземпляра и повторяйте процесс до тех пор, пока все базы данных не будут переключены на резерв.

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

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

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

Очистка после переключения в случае отказа

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

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

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

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

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

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

Сведения об устранении этой проблемы см. в статье Исправление сценария разделения мозга.

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

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

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

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

  • Last updated on