Partilhar via

Ativação pós-falha manual iniciada pelo utilizador no SQL Managed Instance

  • Artigo

Aplica-se a:Instância Gerenciada SQL do Azure

Este artigo explica como fazer failover manual de um nó primário nas camadas de serviço GP (General Purpose) e BC (Business Critical) da Instância Gerenciada SQL e como fazer failover manual de um nó de réplica somente leitura secundário somente na camada de serviço BC.

Nota

Este artigo não está relacionado a failovers entre regiões com grupos de failover.

Quando usar failover manual

A alta disponibilidade é uma parte fundamental da plataforma SQL Managed Instance que funciona de forma transparente para seus aplicativos de banco de dados. As ativações pós-falha executadas a partir dos nós primários para os nós secundários em caso de degradação dos nós ou deteção de falhas, ou durante as atualizações de software mensais normais, são uma ocorrência esperada para todas as aplicações que utilizam o SQL Managed Instance no Azure.

Você pode considerar a execução de um failover manual na Instância Gerenciada SQL por alguns dos seguintes motivos:

  • Testar a resiliência da ativação pós-falha da aplicação antes de ser implementada para produção
  • Testar a resiliência a falhas dos sistemas ponto a ponto em ativações pós-falha automáticas
  • Testar o impacto da ativação pós-falha nas sessões de base de dados existentes
  • Verificar se uma ativação pós-falha modifica o desempenho ponto a ponto devido a alterações na latência da rede
  • Em alguns casos de degradação do desempenho da consulta, a ativação pós-falha manual pode ajudar a mitigar o problema de desempenho.

Nota

Garantir que seus aplicativos sejam resilientes a failover antes da implantação na produção ajuda a reduzir o risco de falhas de aplicativos na produção e contribui para a disponibilidade de aplicativos para seus clientes. Saiba mais sobre como testar seus aplicativos quanto à prontidão para a nuvem com a gravação de vídeo Testando o App Cloud Readiness for Failover Resiliency with SQL Managed Instance .

Iniciar failover manual na instância gerenciada do SQL

Permissões do RBAC do Azure necessárias

Os usuários que iniciam um failover precisam ter uma das seguintes funções do Azure:

  • Função Proprietário da Subscrição ou
  • Função de Colaborador da Instância Gerenciada SQL ou
  • Função personalizada com a seguinte permissão:
    • Microsoft.Sql/managedInstances/failover/action

Através do PowerShell

A versão mínima do Az.Sql precisa ser v2.9.0. Considere usar o Azure Cloud Shell do portal do Azure que sempre tem a versão mais recente do PowerShell disponível.

Como pré-requisito, use o seguinte script do PowerShell para instalar os módulos necessários do Azure. Além disso, selecione a assinatura onde a Instância Gerenciada SQL que você deseja fazer failover está localizada.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Use o comando do PowerShell Invoke-AzSqlInstanceFailover com o exemplo a seguir para iniciar o failover do nó primário, aplicável à camada de serviço BC e GP.

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

Use o seguinte comando do PowerShell para failover de nó secundário de leitura, aplicável somente à camada de serviço BC.

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

Com a CLI

Certifique-se de ter os scripts CLI mais recentes instalados.

Use o comando az sql mi failover CLI com o exemplo a seguir para iniciar o failover do nó primário, aplicável à camada de serviço BC e GP.

az sql mi failover -g myresourcegroup -n myinstancename

Use o seguinte comando da CLI para failover de leitura de nó secundário, aplicável somente à camada de serviço BC.

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

Com a API REST

Para usuários avançados que talvez precisem automatizar failovers de suas instâncias gerenciadas SQL para fins de implementação de pipeline de teste contínuo ou mitigadores de desempenho automatizados, essa função pode ser realizada por meio do início do failover por meio de uma chamada de API. Consulte SQL Managed Instances - Failover REST API para obter detalhes.

Para iniciar o failover usando a chamada da API REST, primeiro gere o token de autenticação usando o cliente de API de sua escolha. O token de autenticação gerado é usado como propriedade Authorization no cabeçalho da solicitação de API e é obrigatório.

O código a seguir é um exemplo do URI da API a ser chamado:

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

As seguintes propriedades precisam ser passadas na chamada de API:

Propriedade API Parâmetro
subscriptionId ID de assinatura na qual a instância gerenciada é implantada
resourceGroupName Grupo de recursos que contém instância gerenciada
managedInstanceName Nome da instância gerenciada
Tipo de réplica (Opcional) (Primário ou LegívelSecundário). Esses parâmetros representam o tipo de réplica a ser submetida a failover: primária ou secundária legível. Se não for especificado, o failover será iniciado na réplica primária por padrão.
api-version Valor estático e atualmente precisa ser "2019-06-01-preview"

A API responde com um dos dois seguintes:

  • 202 Aceito
  • Um dos 400 erros de solicitação.

O status da operação pode ser rastreado por meio da revisão das respostas da API nos cabeçalhos de resposta. Para obter mais informações, consulte Status de operações assíncronas do Azure.

Monitorar o failover

Para monitorar o progresso do failover iniciado pelo usuário para sua instância de BC, execute a seguinte consulta T-SQL em seu cliente favorito (como SSMS) na Instância Gerenciada SQL. Ele lê a visualização do sistema sys.dm_hadr_fabric_replica_states e as réplicas de relatório disponíveis na instância. Atualize a mesma consulta depois de iniciar o failover manual.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Antes de iniciar o failover, sua saída indica a réplica primária atual na camada de serviço BC contendo um primário e três secundários no Grupo de Disponibilidade Always On. Após a execução de um failover, a execução dessa consulta novamente precisaria indicar uma alteração do nó primário.

Você não poderá ver a mesma saída com a camada de serviço GP que a mostrada acima para BC. Isso ocorre porque a camada de serviço GP é baseada em um único nó apenas. Você pode usar uma consulta T-SQL alternativa mostrando a hora em que o processo SQL foi iniciado no nó para a instância da camada de serviço GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

A curta perda de conectividade do cliente durante o failover, normalmente com duração inferior a um minuto, é a indicação da execução do failover, independentemente da camada de serviço.

Nota

A conclusão do processo de failover (não a indisponibilidade curta real) pode levar vários minutos de cada vez no caso de cargas de trabalho de alta intensidade . Isso ocorre porque o mecanismo de instância está cuidando de todas as transações atuais no nó primário e recuperando o atraso no nó secundário, antes de poder fazer failover.

Importante

As limitações funcionais do failover manual iniciado pelo usuário são:

  • Pode haver um (1) failover iniciado na mesma instância gerenciada SQL a cada 15 minutos.
  • Para instâncias de BC, deve existir quórum de réplicas para que a solicitação de failover seja aceita.
  • Para instâncias de BC, não é possível especificar em qual réplica secundária legível iniciar o failover.
  • O failover não será permitido até que o primeiro backup completo de um novo banco de dados seja concluído por sistemas de backup automatizados.
  • O failover não será permitido se houver uma restauração de banco de dados em andamento.

Próximos passos