Compartilhar via

Failover manual iniciado pelo usuário na Instância Gerenciada de SQL

  • Artigo

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

Este artigo explica como fazer failover manual de um nó primário nas camadas de serviço GP (Uso Geral) e BC (Comercialmente Crítico) da Instância Gerenciada de SQL e como fazer failover manual de um nó secundário de réplica somente leitura apenas na camada de serviço BC.

Observação

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

Quando usar o failover manual

A alta disponibilidade é uma parte fundamental da plataforma Instância Gerenciada de SQL que funciona de forma transparente para os aplicativos de banco de dados. A ocorrência de failovers de nós primários para secundários em caso de degradação de nó ou detecção de falha ou durante atualizações de software mensais regulares é esperada para todos os aplicativos que usam a Instância Gerenciada de SQL no Azure.

Considere a possibilidade de executar um failover manual na Instância Gerenciada de SQL por alguns dos seguintes motivos:

  • Testar aplicativos quanto à resiliência a failover antes da implantação na produção
  • Testar sistemas ponta a ponta quanto à resiliência a falhas em failovers automáticos
  • Testar como o failover afeta as sessões de banco de dados existentes
  • Verificar se um failover muda o desempenho de ponta a ponta devido a alterações na latência de rede
  • Em alguns casos de degradação do desempenho de consulta, o failover manual pode ajudar a atenuar o problema de desempenho.

Observação

Garantir que os aplicativos sejam resilientes a failover antes da implantação na produção ajuda a reduzir o risco de falhas do aplicativo na produção e contribui para a disponibilidade do aplicativo aos clientes. Saiba mais sobre como testar a preparação de aplicativos para a nuvem, com a gravação do vídeo Testing App Cloud Readiness for Failover Resiliency with SQL Managed Instance (Testar a preparação para a resiliência a failover do aplicativo para a nuvem com a Instância Gerenciada de SQL).

Iniciar failover manual na Instância Gerenciada de SQL

Permissões do Azure RBAC necessárias

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

Usando o PowerShell

A versão mínima do Az.Sql precisa ser v 2.9.0. Considere a possibilidade de usar sempre o Azure Cloud Shell do portal do Azure que tenha a versão mais recente do PowerShell disponível.

Como pré-requisito, use o script do PowerShell a seguir para instalar os módulos do Azure necessários. Além disso, selecione a assinatura em que está localizada a Instância Gerenciada de SQL que sofrerá o failover.

$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 Invoke-AzSqlInstanceFailover do PowerShell com o exemplo a seguir para iniciar o failover do nó primário, aplicável às camadas 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 comando do PowerShell a seguir para fazer failover do 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

Usando a CLI

Verifique se você tem os scripts da CLI mais recentes instalados.

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

az sql mi failover -g myresourcegroup -n myinstancename

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

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

Usando a API REST

Para usuários avançados que talvez precisem automatizar os failovers das Instâncias Gerenciadas de SQL com a finalidade de implementar pipeline de teste contínuo, ou mitigadores de desempenho automatizados, esta função pode ser realizada iniciando o failover por meio de uma chamada à API. Consulte Instâncias gerenciadas de SQL – API REST de failover para obter detalhes.

Para iniciar o failover com a chamada à API REST, primeiro gere o token de autenticação usando o cliente de API de sua preferência. O token de autenticação gerado atua como propriedade de autorização no cabeçalho da solicitação de API e é obrigatório.

Este código é um exemplo de URI da API para a chamada:

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

As propriedades a seguir precisam ser transmitidas na chamada à API:

Propriedade da API Parâmetro
subscriptionId ID de assinatura em que a instância gerenciada é implantada
resourceGroupName Grupo de recursos que contém a instância gerenciada
managedInstanceName Nome da instância gerenciada
replicaType (Opcional) (Primary ou ReadableSecondary). Estes parâmetros representam o tipo de réplica que sofrerá failover: primária ou secundária para leitura. Se não for especificado, o failover será iniciado na réplica primária por padrão.
api-version O valor estático; no momento precisa ser "2019-06-01-preview"

A API responde com uma destas duas opções:

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

O status da operação pode ser acompanhado com a análise das respostas da API nos cabeçalhos de resposta. Para obter mais informações, confira Status de operações assíncronas do Azure.

Monitorar o failover

Para monitorar o progresso do failover iniciado pelo usuário para a instância de BC, execute a seguinte consulta T-SQL no seu cliente favorito (SSMS, por exemplo) na Instância Gerenciada de SQL. Ela lê a exibição do sistema sys.dm_hadr_fabric_replica_states e relata as réplicas 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, a saída indica a réplica primária atual na camada de serviço BC que contém um primário e três secundários no grupo de disponibilidade Always On. Após a execução de um failover, a repetição dessa consulta precisará indicar uma alteração do nó primário.

Não será possível ver a mesma saída com a camada de serviço GP, conforme mostrado acima para BC. Isso ocorre porque a camada de serviço GP é baseada apenas em um único nó. Você pode usar a consulta T-SQL alternativa que mostra a hora em que o processo SQL foi iniciado no nó referente à instância da camada de serviço GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

A pequena perda de conectividade do cliente durante o failover, normalmente por menos de um minuto, indica que o failover foi executado, independentemente da camada de serviço.

Observação

No caso de cargas de trabalho de alta intensidade, a conclusão do processo de failover (e não a curta indisponibilidade real) pode levar vários minutos seguidos. Isso ocorre porque o mecanismo de instância atende a todas as transações atuais no nó primário e atualiza o nó secundário, antes de poder realizar o failover.

Importante

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

  • Pode haver um (1) failover iniciado na mesma Instância Gerenciada de SQL a cada 15 minutos.
  • Para instâncias de BC, deve existir um quorum 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 para leitura o failover será iniciado.
  • O failover não será permitido enquanto o primeiro backup completo de um novo banco de dados não for 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óximas etapas