Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
Azure SQL Managed Instance
Este artigo explica como reiniciar a Instância Gerenciada SQL do Azure executando um failover manual iniciado pelo usuário usando o PowerShell, a CLI do Azure ou a API REST.
É possível executar failover de um nó primário nas camadas de serviço GP (General Purpose) e Business Critical (BC), e executar failover manual de um nó de réplica secundário de leitura apenas 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 um grupo de failover.
Quando se deve usar o processo de comutação manual
A disponibilidade, uma parte fundamental da plataforma de Instância Gerenciada SQL, funciona de forma transparente para seus aplicativos de banco de dados, fornecendo nós de computação em espera locais para hospedar o processo do mecanismo de banco de dados do SQL Server. Ocorre um failover quando o processo do motor de base de dados do SQL Server é desligado e ligado novamente no mesmo nó de computação ou em outro nó. Normalmente, os failovers são automáticos e gerenciados pela plataforma Azure quando uma falha é detetada, um nó é 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, finalmente, redirecionar as conexões do cliente para o novo processo SQL. As conexões de cliente só falham por um curto período de tempo, geralmente menos de um minuto, durante a etapa final da operação de failover.
Poderá executar um failover manual para reiniciar o processo do motor pelas seguintes razões:
- Logins com falha ou lentidão devido a problemas de desempenho.
- Testar a aplicação para a resiliência a falhas antes de a implementar em produção.
- Testando sistemas de ponta a ponta quanto à resiliência a falhas em failovers automáticos.
- Testando 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 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 à preparação para a nuvem com o seguinte vídeo:
A tabela a seguir descreve o comportamento esperado da Instância Gerenciada SQL durante uma operação de failover com base na camada de serviço e no modelo de disponibilidade:
| Escalão de serviço | Modelo de disponibilidade | Comportamento de failover esperado | Comportamento em caso de falha potencial (exceções) |
|---|---|---|---|
| Finalidade Geral |
Redundância local (Zona de disponibilidade única) |
O processo SQL é reiniciado na mesma VM. | O processo SQL é reiniciado em uma VM diferente. |
| Finalidade 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. |
| Crítico para a Empresa |
Redundância local (Zona de disponibilidade única) |
O processo SQL é reiniciado na réplica primária ou a réplica secundária aleatória é promovida para primária. | N/A |
| Crítico para a Empresa |
Redundância de zona (Várias zonas de disponibilidade) |
O processo SQL é reiniciado na réplica primária ou a réplica secundária aleatória é promovida para primária, na mesma zona de disponibilidade ou em zonas de disponibilidade diferentes. | N/A |
Permissões
Os usuários que iniciam um failover precisam ter uma das seguintes funções do Azure:
- Função de proprietário de 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
Reiniciar uma instância com um failover manual
Você pode reiniciar uma instância com um failover manual usando o PowerShell, a CLI do Azure ou a API REST.
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 subscrição onde se encontra a Instância Gerida SQL na qual deseja realizar 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 PowerShell Invoke-AzSqlInstanceFailover com o exemplo a seguir para iniciar o failover do nó primário, aplicável a ambas as 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 realizar o failover do nó secundário de leitura, aplicável exclusivamente à camada de serviço BC.
$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary
Monitorizar a comutação por falha
Monitorizar o progresso de um failover iniciado pelo utilizador difere para instâncias nas camadas de serviço "Business Critical" e "General Purpose".
Para monitorar o progresso de um failover iniciado pelo usuário, use:
- sys.dm_os_sys_info verificar o tempo de atividade do sistema para a camada de serviço de uso geral .
-
sys.dm_hadr_fabric_replica_statespara verificar as réplicas disponíveis para a camada de serviço Crítico para Negócios.
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 seu cliente durante o failover, normalmente com duração inferior a um minuto, indica que o failover foi bem-sucedido - independentemente da camada de serviço.
Nível de serviço de uso geral
O exemplo T-SQL a seguir mostra o tempo de atividade do processo SQL no nó da camada de serviço de propósito 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 é atualizado após cada 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.
Nível de serviço crítico para os negócios
O exemplo de T-SQL a seguir indica qual nó é atualmente a réplica primária para a camada de serviço Business Critical :
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 Business Critical para monitorar o progresso da operação de failover.
Observação
O processo de failover completo pode levar vários minutos a ser concluído durante cargas de trabalho de alta intensidade, pois o mecanismo da instância garante que as transações no nó secundário estejam alinhadas com as do nó primário antes de iniciar o processo de failover.
Limitações
Considere as seguintes limitações funcionais dos failovers manuais iniciados pelo utilizador:
- Só pode haver um (1) failover iniciado na mesma instância gerenciada do SQL a cada 15 minutos.
- Não são permitidos failovers:
- Até que o primeiro backup completo para um novo banco de dados seja concluído por sistemas de backup automatizados.
- se houver restauração do banco de dados em andamento.
- Para instâncias na camada de serviço Crítica para os Negócios:
- As réplicas devem ter um quórum antes que uma solicitação de failover seja aceita.
- O
Invoke-AzSqlInstanceFailovercomando realiza failover na réplica primária, a menos que-ReadableSecondaryseja especificado, caso em que a réplica secundária legível fará failover. As réplicas secundárias não legíveis não fazem a transição quando este comando é executado.
Conteúdo relacionado
- Saiba mais sobre como testar as suas aplicações quanto à prontidão para a nuvem com Testar a Prontidão para Nuvem de Aplicações para Resiliência a Falhas com SQL Managed Instance na gravação de vídeo.
- Saiba mais sobre alta disponibilidade de instância gerenciada Alta disponibilidade para Instância Gerenciada SQL do Azure.
- Para obter uma visão geral, consulte O que é a Instância Gerenciada SQL do Azure?.