Compartilhar via

Reiniciar uma instância com um failover manual iniciado pelo usuário – Instância Gerenciada de SQL do Azure

  • Artigo

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

Este artigo explica como reiniciar a Instância Gerenciada de SQL do Azure executando um failover manual iniciado pelo usuário para um nó de computação secundário usando o PowerShell, a CLI do Azure ou a API REST.

É possível fazer failover manual de um nó primário nas camadas de serviço GP (Uso Geral) e BC (Comercialmente Crítico) e fazer failover manual de um nó secundário de réplica somente leitura na camada de serviço BC.

Observação

O failover neste artigo refere-se ao início do processo do mecanismo de banco de dados do SQL Server em um nó secundário e não está relacionado ao failover entre regiões de grupos de failover.

Quando usar o failover manual

A disponibilidade, uma parte fundamental da plataforma de Instância Gerenciada de SQL, funciona de forma transparente para seus aplicativos de banco de dados, fornecendo nós de computação em espera local para hospedar o processo do mecanismo de banco de dados do SQL Server. Um failover ocorre quando o processo do mecanismo de banco de dados do SQL Server é colocado offline no nó de computação primário e é colocado online em um nó de computação secundário. Normalmente, os failovers entre nós de computação da instância gerenciada de SQL são automáticos e gerenciados pela plataforma quando uma falha é detectada, um nó é degradado ou durante atualizações de software mensais regulares.

Toda a operação de failover consiste em colocar o processo do mecanismo de banco de dados do SQL Server online em um nó secundário, validar o estado do banco de dados e, finalmente, redirecionar as conexões do cliente para o novo nó primário. As conexões do cliente falham apenas por um curto período de tempo, normalmente menos de um minuto, durante a etapa final da operação de failover.

Você pode executar um failover manual para reiniciar o processo do mecanismo em um nó diferente pelos seguintes motivos:

  • Logons com falha ou lentidão devido a problemas de desempenho.
  • Testar o aplicativo quanto à resiliência a failover antes da implantação em produção.
  • Testar os sistemas de 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.
  • Degradação do desempenho da consulta (reiniciar a instância pode ajudar a atenuar o problema de desempenho).

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 seus aplicativos para preparação para a nuvem assistindo ao seguinte vídeo:

A tabela a seguir descreve o comportamento esperado da Instância Gerenciada de SQL durante uma operação de failover com base na camada de serviço e no modelo de disponibilidade:

Camada de serviço Modelo de disponibilidade Outro comportamento esperado Comportamento de failover potencial (exceções)
Uso Geral Redundância de zona
(Zona de disponibilidade única)		 O processo SQL é reiniciado na mesma VM. O processo SQL é reiniciado em uma VM diferente.
Uso Geral Redundância de zona (preview)
(Várias zonas de disponibilidade)		 O processo SQL é reiniciado na mesma VM. O processo SQL é reiniciado em uma VM diferente.
Comercialmente Crítico Redundância de zona
(Zona de disponibilidade única)		 A réplica secundária aleatória é promovida a primária. N/D
Comercialmente Crítico Redundância de zona
(Várias zonas de disponibilidade)		 A réplica secundária aleatória é promovida a primária, na mesma zona de disponibilidade ou em uma zona de disponibilidade diferente. N/D

Permissões

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

Reiniciar uma instância com um failover manual

Você pode reiniciar uma instância com um failover manual usando a API REST, o PowerShell ou a CLI do Azure.

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

Monitorar o failover

O monitoramento do progresso de um failover iniciado pelo usuário difere para instâncias nas camadas de serviço Comercialmente Crítico e de Uso Geral.

Para monitorar o progresso de um failover iniciado pelo usuário, use:

  • sys.dm_os_sys_info para verificar o tempo de atividade do sistema para a camada de serviço de Uso Geral.
  • sys.dm_hadr_fabric_replica_states para verificar as réplicas disponíveis para a camada de serviço Comercialmente Crítico.

A etapa final do processo de failover é o redirecionamento das conexões do cliente para o novo nó primário. 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.

Camada de serviço de Uso Geral

O exemplo de T-SQL a seguir mostra o tempo de atividade do processo SQL no nó da camada de serviço de Uso Geral:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

A hora de início do processo SQL é a hora em que o processo do mecanismo de banco de dados do SQL Server foi iniciado no nó. O tempo é reiniciado após a conclusão do failover. Execute essa consulta antes e depois de iniciar um failover de uma instância na camada de serviço de Uso Geral para monitorar o progresso da operação de failover.

Camada de serviço comercialmente crítica

O exemplo de T-SQL a seguir indica qual nó é atualmente a réplica primária para a camada de serviço Comercialmente Crítico:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

O nó que hospeda a réplica primária é alterado após a conclusão do failover. Execute essa consulta antes e depois de iniciar um failover de uma instância na camada de serviço Comercialmente Crítico para monitorar o progresso da operação de failover.

Observação

O processo de failover completo pode levar vários minutos para ser concluído durante cargas de trabalho de alta intensidade porque o mecanismo de instância garante que as transações no nó secundário sejam capturadas para as transações do nó primário antes de iniciar o failover.

Limitações

Considere as seguintes limitações funcionais de failovers manuais iniciados pelo usuário:

  • Só pode haver um (1) failover iniciado na mesma Instância Gerenciada de SQL a cada 15 minutos.
  • Failovers não são permitidos:
    • Enquanto o primeiro backup completo de um novo banco de dados não for concluído por sistemas de backup automatizados.
    • Se houver alguma restauração de banco de dados em andamento.
  • Para instâncias na camada de serviço Comercialmente Crítico:
    • Deve haver um quorum de réplicas para que a solicitação de failover seja aceita.
    • Não é possível especificar em qual réplica secundária para leitura o failover será iniciado.

Conteúdo relacionado