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

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

  • Статья

Применимо к:Управляемый экземпляр SQL Azure

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

Примечание.

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

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

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

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

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

Примечание.

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

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

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

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

  • роль владельца подписки; или
  • роль участника Управляемый экземпляр SQL или
  • настраиваемая роль со следующим разрешением: .
    • Microsoft.Sql/managedInstances/failover/action

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

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

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

$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

Используйте следующую команду PowerShell для отработки отказа вторичного узла, применимого только к уровню служб 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. Дополнительные сведения см. в Управляемый экземпляр SQL — 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 Идентификатор подписки, в которой развернут управляемый экземпляр
resourceGroupName Группа ресурсов, содержащая управляемый экземпляр
managedInstanceName Имя управляемого экземпляра
replicaType (Необязательно) (Primary или ReadableSecondary). Эти параметры представляют тип реплики для отработки отказа: первичная или вторичная для чтения. Если это не указано, по умолчанию выполняется отработка отказа на первичном реплика.
api-version Статические значения и в настоящее время должны быть "2019-06-01-preview"

API отвечает одним из следующих двух:

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

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

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

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

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

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

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

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

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

Примечание.

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

Важно!

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

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

Следующие шаги