Compartilhar via

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

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 usando o PowerShell, a CLI do Azure ou a API REST.

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

Observação

O failover neste artigo refere-se à reinicialização do processo do mecanismo de banco de dados do SQL Server 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. Ocorre um failover quando o processo do mecanismo de banco de dados do SQL Server é colocado offline e é colocado online no mesmo nó de computação ou em outro. Normalmente, os failovers são automáticos e gerenciados pela plataforma Azure quando uma falha é detectada, um nó está degradado ou durante atualizações de serviço.

Toda a operação de failover consiste em colocar o processo do mecanismo de banco de dados do SQL Server online, validar o estado do banco de dados e, por fim, redirecionar as conexões do cliente para o novo processo do SQL. 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 pelos seguintes motivos:

  • Logons com falha ou lentidão devido a problemas de desempenho.
  • Antes da implantação em produção, teste a resiliência do aplicativo a falhas (failover).
  • Testar sistemas ponta a ponta para 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 Comportamento esperado do failover Comportamento potencial do failover (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
(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)		 O processo do SQL é reiniciado na réplica primária ou uma réplica secundária aleatória é promovida a primária. N/A
Comercialmente Crítico Redundância de zona
(Várias zonas de disponibilidade)		 O processo do SQL é reiniciado na réplica primária ou uma réplica secundária aleatória é promovida a primária, na mesma zona de disponibilidade ou em outra. N/A

Permissões

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

Reiniciar uma instância com 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 seguinte comando do PowerShell 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 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 curta perda de conectividade do cliente durante o failover, geralmente inferior a um minuto, indica que o failover foi bem-sucedido, independentemente da camada de serviço.

Camada de serviço Uso Geral

O exemplo de T-SQL a seguir mostra o tempo de atividade do processo SQL no nó para a camada de serviço 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ó, que é atualizada após cada failover. Execute esta consulta antes e depois de iniciar um failover de uma instância na camada de serviço 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 esta 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 completo de failover 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 alcancem 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:
    • As réplicas devem ter quorum antes que uma solicitação de failover seja aceita.
    • O comando Invoke-AzSqlInstanceFailover faz failover da réplica primária, a menos que -ReadableSecondary seja especificado, nesse caso, a réplica secundária para leitura fará failover. As réplicas secundárias não disponíveis para leitura não fazem failover quando este comando é emitido.

Conteúdo relacionado

  • Last updated on