Инициированный пользователем переход на другой ресурс вручную на Управляемом экземпляре SQL

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

В этой статье объясняется, как перейти на другой ресурс вручную для основного узла на уровнях служб Управляемый экземпляр SQL общего назначения (GP) и Критически важный для бизнеса (BC) и как перейти на другой ресурс вручную для вторичного узла реплики только для чтения на уровне службы BC.

Примечание

Эта статья не связана с отработками отказа между регионами в группах автоматической отработки отказа.

Когда следует использовать отработку отказа вручную

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

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

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

Примечание

Обеспечение отказоустойчивости приложений до развертывания в рабочей среде поможет снизить риск сбоев приложений в рабочей среде и повлиять на доступность приложений для ваших клиентов. Узнайте больше о тестировании приложений на готовность к работе в облаке с помощью тестирования готовности к отработке отказа с помощью перекодирования видео управляемого экземпляра SQL.

Запуск отработки отказа вручную на Управляемом экземпляре SQL

Требуются разрешения RBAC Azure

Пользователь, инициирующий отработку отказа, должен иметь одну из следующих ролей Azure:

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

Минимальная версия Az.Sql — v 2.9.0. Рассмотрите возможность использования Azure Cloud Shell из портала Azure, где всегда доступна последняя версия PowerShell.

Предварительное требование: используйте следующий сценарий PowerShell для установки необходимых модулей Azure. Кроме того, выберите подписку, в которой находится Управляемый экземпляр, для которого требуется выполнить отработку отказа.

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Используйте команду PowerShell Invoke-AzSqlInstanceFailover в следующем примере, чтобы инициировать отработку отказа основного узла, применимую к уровню служб BC и GP.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

Используйте следующую команду PS для отработки отказа для вторичного узла, она применяется только для уровня служб BC.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

Использование синтаксиса командной строки

Убедитесь, что установлены последние версии скриптов CLI.

Используйте команду CLI "az sql mi failover" в следующем примере, чтобы инициировать отработку отказа основного узла, применимую к уровню служб BC и GP.

az sql mi failover -g myresourcegroup -n myinstancename

Используйте следующую команду CLI для отработки отказа для вторичного узла, она применяется только для уровня служб BC.

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

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

Для опытных пользователей, которым, возможно, потребуется автоматизировать отработку отказа управляемых экземпляров SQL в целях реализации непрерывного конвейера тестирования или автоматизированных механизмов снижения производительности, эту функцию можно выполнить, инициируя отработку отказа через вызов API. Дополнительные сведения см. в разделе Управляемые экземпляры — REST API для отработки отказов.

Чтобы инициировать отработку отказа с помощью вызова REST API, сначала создайте маркер проверки подлинности с помощью клиента API по вашему выбору. Созданный маркер проверки подлинности используется в качестве свойства авторизации в заголовке запроса API и является обязательным.

В следующем коде показан пример текучего универсального кода ресурса (URI) API:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

При вызове API необходимо передать следующие свойства:

Свойство API Параметр
subscriptionId Идентификатор подписки, в которой развернут управляемый экземпляр
имя_группы_ресурсов Группа ресурсов, содержащая управляемый экземпляр
managedInstanceName Имя управляемого экземпляра
replicaType (Необязательно) (Primary или ReadableSecondary). Эти параметры представляют тип реплики для отработки отказа: первичная или вторичная для чтения. Если этот параметр не указан, по умолчанию отработка отказа будет инициирована в первичной реплике.
api-version Статическое значение, в настоящее время "2019-06-01-preview"

API отправляет один из следующих двух ответов:

  • 202 — принято
  • Одна из ошибок запроса 400.

Состояние операции можно отследить путем анализа ответов API в заголовках ответа. Дополнительные сведения см. в разделе Состояние асинхронных операций Azure.

Контроль отработки отказа

Чтобы отслеживать ход выполнения отработки отказа, инициированной пользователем для экземпляра BC, выполните следующий запрос T-SQL в вашем предпочтительном клиенте (например, SSMS) на Управляемом экземпляре SQL. Будет прочитано системное представление sys.dm_hadr_fabric_replica_states и реплики отчетов, доступные в экземпляре. Обновите этот запрос после инициации отработки отказа вручную.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

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

Вы не увидите те же выходные данные на уровне служб GP, как показано выше для BC. Это связано с тем, что уровень служб GP основан только на одном узле. Можно использовать альтернативный запрос T-SQL, показывающий время запуска процесса SQL на узле для экземпляра уровня службы GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

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

Примечание

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

Важно!

Функциональные ограничения инициированной пользователем ручной отработки отказа:

  • Возможна одна (1) отработка отказа, инициированная на одном управляемом экземпляре каждые 15 минут.
  • Для экземпляров BC требуется кворум реплик, чтобы запрос отработки отказа был принят.
  • Для экземпляров BC невозможно указать, на какой вторичной реплике для чтения будет выполняться отработка отказа.
  • Отработка отказа не будет разрешена, пока не завершится создание первой полной резервной копии для новой базы данных с помощью автоматизированных систем резервного копирования.
  • Отработка отказа не будет разрешена, если выполняется восстановление базы данных.

Дальнейшие действия