Configurar um grupo de failover para uma Instância Gerenciada de SQL do Azure

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

• Banco de Dados SQL do Azure
• Instância Gerenciada do SQL do Azure

Este artigo ensina como configurar um grupo de failover para a Instância Gerenciada de SQL do Azure usando o portal do Azure e o Azure PowerShell.

Para obter um script do PowerShell de ponta a ponta para criar ambas as instâncias em um grupo de failover, revise Adicionar instância a um grupo de failover.

Pré-requisitos

Considere os seguintes pré-requisitos:

• A instância gerenciada secundária precisa estar vazia, ou seja, não conter bancos de dados de usuário.
• As duas instâncias da Instância Gerenciada de SQL precisam ser da mesma camada de serviço e ter o mesmo tamanho de armazenamento. Embora não seja necessário, é altamente recomendável que duas instâncias tenham um tamanho de computação igual, a fim de garantir que a instância secundária possa processar de maneira sustentável as alterações que estão sendo replicadas da instância primária, incluindo os períodos de atividade de pico.
• O Intervalo de endereços IP para a rede virtual da instância primária não deve se sobrepor ao intervalo de endereços da rede virtual para a instância gerenciada secundária, ou qualquer outra rede virtual emparelhada com a rede virtual primária ou secundária.
• Ao criar sua instância gerenciada secundária, você deve especificar o ID da zona DNS da instância primária como o valor do parâmetro DnsZonePartner. Se você não especificar um valor para DnsZonePartner, a ID da zona gerada como uma sequência aleatória quando a primeira instância for criada em cada rede virtual, e a mesma ID será atribuída a todas as outras instâncias da mesma sub-rede. Uma vez atribuída, a zona DNS não pode ser modificada.
• As regras de NSG (grupos de segurança de rede) na sub-rede que hospeda a instância precisam ter a porta 5022 (TCP) e o intervalo de portas 11000-11999 (TCP) aberto de entrada e saída para conexões na sub-rede que hospeda a outra instância gerenciada. Isso se aplica às duas sub-redes, que hospedam as instâncias primária e secundária.
• O agrupamento e o fuso horário da instância gerenciada secundária devem corresponder ao da instância gerenciada primária.
• As instâncias gerenciadas devem ser implantadas em regiões emparelhadas por motivos de desempenho. As instâncias gerenciadas que se encontram em regiões com emparelhamento geográfico se beneficiam de uma velocidade consideravelmente maior de duplicação geográfica em comparação com regiões não emparelhadas.

Intervalo de espaço de endereço

Para verificar o espaço de endereço da instância primária, vá para o recurso de rede virtual da instância primária e selecione Espaço de endereço em Configurações. Verifique o intervalo em Intervalo de endereços:

Especificar o ID da zona da instância primária

Ao criar sua instância secundária, você deve especificar o ID de zona da instância primária como o DnsZonePartner.

Portal

Se você estiver criando sua instância secundária no portal do Azure, na guia Configurações adicionais, em Replicação geográfica, escolha Sim para Usar como failover secundário e selecione a instância primária na lista suspensa:

PowerShell

Se você estiver criando sua instância secundária com o Azure PowerShell, certifique-se de fornecer ao parâmetro DnsZonePartner a ID de zona da instância primária.

Você pode usar o comando Get-AzSqlInstance para parametrizar o ID da zona DNS da instância primária e, em seguida, passá-lo para o parâmetro DnsZonePartner do comando New-AzSqlInstance:

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

Como habilitar a conectividade entre as instâncias

A conectividade entre as sub-redes de rede virtual que hospedam a instância primária e secundária precisa ser estabelecida e mantida para um fluxo de tráfego de replicação geográfica ininterrupto. Há várias maneiras de estabelecer a conectividade entre as instâncias gerenciadas em diferentes regiões do Azure, incluindo:

• Emparelhamento de rede virtual global
• Azure ExpressRoute
• Gateways VPN

O emparelhamento de rede virtual global é recomendado como a maneira mais eficiente e robusta de estabelecer a conectividade entre instâncias em um grupo de failover. O emparelhamento de rede virtual fornece uma conexão privada de baixa latência e alta largura de banda entre as redes virtuais emparelhadas usando a infraestrutura de backbone da Microsoft. Não são necessários a Internet pública, os gateways ou a criptografia adicional na comunicação entre as redes virtuais emparelhadas.

Importante

Maneiras alternativas de conectar instâncias que envolvem dispositivos de rede adicionais podem complicar a solução de problemas de conectividade ou velocidade de duplicação, possivelmente exigindo o envolvimento ativo dos administradores de rede e potencialmente prolongando significativamente o tempo de resolução.

Independentemente do mecanismo de conectividade, há requisitos que devem ser atendidos para que o tráfego de replicação geográfica flua:

• A tabela de rotas e os grupos de segurança de rede atribuídos a sub-redes de instâncias gerenciadas não são compartilhados entre as duas redes virtuais emparelhadas.
• As regras do grupo de segurança de rede (NSG) na sub-rede que hospeda a instância primária permitem:
  • Tráfego de entrada na porta 5022 e no intervalo de portas 11000-11999 da sub-rede que hospeda a instância secundária.
  • Tráfego de saída na porta 5022 e no intervalo de portas 11000-11999 para a sub-rede que hospeda a instância secundária.
• As regras do Grupo de Segurança de Rede (NSG) na instância secundária de hospedagem de sub-rede permitem:
  • Tráfego de entrada na porta 5022 e no intervalo de portas 11000-11999 da sub-rede que hospeda a instância primária.
  • Tráfego de saída na porta 5022 e no intervalo de portas 11000-11999 para a sub-rede que hospeda a instância primária.
• Os intervalos de endereço IP de VNets que hospedam a instância primária e a secundária não devem se sobrepor.
• Não há sobreposição indireta de intervalos de endereço IP entre as VNets que hospedam a instância primária e a secundária e outras VNets com as quais elas são emparelhadas por meio de emparelhamento de rede virtual local ou outros meios.

Além disso, se você estiver usando mecanismos para fornecer conectividade entre as instâncias que não sejam o emparelhamento de rede virtual global recomendado, você precisará garantir o seguinte:

• Os dispositivos de rede usados, como firewalls ou NVAs (soluções de virtualização de rede), não bloqueiam o tráfego nas portas mencionadas anteriormente.
• O roteamento está configurado corretamente, e o roteamento assimétrico é evitado.
• Se você implantar grupos de failover em uma topologia de rede de hub e spoke entre regiões, o tráfego de duplicação deverá passar diretamente entre as duas sub-redes da instância gerenciada, em vez de ser direcionado pelas redes de hub. Isso ajuda você a evitar problemas de conectividade e velocidade de duplicação.

Portal

1. No portal do Azure, acesse o recurso Rede virtual da instância gerenciada primária.
2. Selecione Emparelhamentos em Configurações e escolha + Adicionar.

1. Insira ou selecione valores para as seguintes configurações:

   Configurações	Descrição
   Esta rede virtual
   Nome do link de emparelhamento	o nome para o emparelhamento deve ser exclusivo na rede virtual.
   Tráfego para a rede virtual remota	Selecione Permitir (padrão) para habilitar a comunicação entre as duas redes virtuais por meio do fluxo VirtualNetwork padrão. Ao habilitar a comunicação entre redes virtuais, os recursos conectados a qualquer uma delas podem se comunicar entre si com a mesma largura de banda e latência que teriam se estivessem conectados à mesma rede virtual. Todas as comunicações entre os recursos nas duas redes virtuais estão na rede privada do Azure.
   Tráfego encaminhado da rede virtual remota	A opção Permitido (padrão) e Bloquear funcionará para este tutorial. Para saber mais, confira Criar um emparelhamento
   Gateway de rede virtual ou Servidor de Rota	Selecione Nenhum. Para obter mais informações sobre as outras opções disponíveis, confira Criar um emparelhamento.
   Rede virtual remota
   Nome do link de emparelhamento	O nome do mesmo emparelhamento a ser usado na rede virtual que hospeda a instância secundária.
   Modelo de implantação de rede virtual	Selecione Gerenciador de recursos.
   Conheço minha ID do recurso	Mantenha essa caixa de seleção desmarcada.
   Subscription	Selecione a assinatura do Azure da rede virtual que hospeda a instância secundária com a qual você deseja fazer o emparelhamento.
   Rede virtual	Escolha a rede virtual que hospeda a instância secundária com a qual você deseja fazer o emparelhamento. Se uma rede virtual estiver listada, mas esmaecida, isso poderá ser devido ao espaço de endereço da rede virtual estar sobreposto ao espaço de endereço dessa rede virtual. Se os espaços de endereço da rede virtual se sobreporem, elas não poderão ser emparelhadas.
   Tráfego para a rede virtual remota	Selecione Permitir (padrão)
   Tráfego encaminhado da rede virtual remota	A opção Permitido (padrão) e Bloquear funcionará para este tutorial. Para saber mais, confira Criar um emparelhamento.
   Gateway de rede virtual ou Servidor de Rota	Selecione Nenhum. Para obter mais informações sobre as outras opções disponíveis, confira Criar um emparelhamento.

2. Selecione Adicionar para configurar o emparelhamento com a rede virtual escolhida. Depois de alguns segundos, selecione o botão Atualizar e o status do emparelhamento será alterado de Atualizando para Conectado.

   

PowerShell

Configure um emparelhamento de rede virtual global entre as redes das instâncias gerenciadas primária e secundária:

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Esse snippet de código usa os seguintes comandos:

Comando	Observações
1. Get-AzVirtualNetwork	Obtém uma rede virtual em um grupo de recursos.
2. Add-AzVirtualNetworkPeering	Adiciona um emparelhamento a uma rede virtual.
3. Get-AzVirtualNetworkPeering	Obtém um emparelhamento para uma rede virtual.

Criar o grupo de failover

Crie o grupo de failover para a instância gerenciada usando o portal do Azure ou o PowerShell.

Portal

Crie o grupo de failover para a Instância Gerenciada de SQL usando o portal do Azure.

1. Selecione SQL do Azure no menu de navegação do portal do Azure à esquerda. Se SQL do Azure não estiver na lista, selecione Todos os serviços e digite SQL do Azure na caixa de pesquisa. (Opcional) Selecione a estrela ao lado de SQL do Azure para adicioná-lo como um item favorito no menu de navegação à esquerda.

2. Selecione a instância gerenciada primária que você deseja adicionar ao grupo de failover.

3. Em Configurações, procure Grupos de Failover da Instância e escolha Adicionar grupo para abrir a página de criação do grupo de failover da instância.

   

4. Na página Grupo de Failover da Instância, digite o nome do grupo de failover e escolha a instância gerenciada secundária na lista suspensa. Selecione Criar para criar o grupo de failover.

   

5. Após a conclusão da implantação do grupo de failover, você será levado novamente à página Grupo de failover.

PowerShell

Use New-AzSqlDatabaseInstanceFailoverGroup para criar o grupo de failover para suas instâncias gerenciadas usando o PowerShell.

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Failover de Teste

Teste o failover do grupo de failover usando o portal do Azure ou o PowerShell.

Portal

Teste o failover do grupo de failover usando o portal do Azure.

1. Procure a instância gerenciada secundária no portal do Azure e selecione Grupos de Failover da Instância em configurações.

2. Observe as instâncias gerenciadas na primária e na função secundária.

3. Selecione Failover e escolha Sim no aviso sobre a desconexão das sessões do TDS.

   

4. Observe as instâncias gerenciadas na primária e na função secundária. Se o failover tiver sido bem-sucedido, as duas instâncias deverão ter alternado as funções.

   

Importante

Se as funções não forem alternadas, verifique a conectividade entre as instâncias e as regras de NSG e de firewall relacionadas. Prossiga com a próxima etapa somente após a troca de funções.

1. Acesse a nova instância gerenciada secundária e selecione failover novamente para fazer failback da instância primária na função primária.

PowerShell

Teste o failover planejado fazendo failover para a réplica secundária e, em seguida, fazendo failback.

Verificar as funções de cada servidor

Use o comando Get-AzSqlDatabaseInstanceFailoverGroup para confirmar as funções de cada servidor:

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Fazer failover no servidor secundário

Use o Switch-AzSqlDatabaseFailoverGroup para fazer failover para o servidor secundário.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

Reverter o grupo de failover de volta para o servidor primário

Use o comando Switch-AzSqlDatabaseFailoverGroup para fazer failback no servidor primário.

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Verificar as funções de cada servidor

Use o comando Get-AzSqlDatabaseFailoverGroup para confirmar as funções de cada servidor.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Fazer failover no servidor secundário

Use o Switch-AzSqlDatabaseFailoverGroup para fazer failover para o servidor secundário.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Reverter o grupo de failover de volta para o servidor primário

Use o comando Switch-AzSqlDatabaseFailoverGroup para fazer failback no servidor primário.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

Localizar ponto de extremidade do ouvinte

Quando o grupo de failover estiver configurado, atualize a cadeia de conexão do seu aplicativo para o ponto de extremidade do ouvinte. Isso manterá seu aplicativo conectado ao ouvinte do grupo de failover, em vez do banco de dados primário, do pool elástico ou do banco de dados de instância. Dessa forma, você não precisa atualizar manualmente a cadeia de conexão toda vez que a entidade do banco de dados falhar e o tráfego é roteado para qualquer entidade que seja primária no momento.

O ponto de extremidade do ouvinte está na forma de fog-name.database.windows.net e fica visível no portal do Azure, ao exibir o grupo de failover:

Criar um grupo entre instâncias em assinaturas diferentes

Você pode criar um grupo de failover entre Instâncias Gerenciadas de SQL em duas assinaturas diferentes, desde que as assinaturas estejam associadas ao mesmo locatário do Microsoft Entra tenanty.

• Ao usar a API do PowerShell, você pode fazer isso especificando o parâmetro PartnerSubscriptionId para a Instância Gerenciada de SQL secundária.
• Ao usar a API REST, cada ID de instância incluída no parâmetro properties.managedInstancePairs pode ter sua própria SubscriptionID.
• O portal do Azure não dá suporte à criação de grupos de failover em assinaturas diferentes.

Importante

Não dá suporte à criação de grupos de failover em assinaturas diferentes no portal do Azure. Para os grupos de failover em diferentes assinaturas e/ou grupos de recursos, o failover não pode ser iniciado manualmente por meio do portal do Azure da instância gerenciada de SQL primária. Em vez disso, inicie-o na instância secundária geográfica.

Evitar a perda de dados críticos

Devido à alta latência das redes de longa distância, a replicação geográfica usa um mecanismo de replicação assíncrona. Com a replicação assíncrona, é impossível evitar a perda de dados em caso de falha no primário. Para proteger as transações críticas contra a perda de dados, um desenvolvedor de aplicativos pode chamar o procedimento armazenado sp_wait_for_database_copy_sync imediatamente após a confirmação da transação. Chamar sp_wait_for_database_copy_sync bloqueia o thread de chamada até que a última transação confirmada seja transmitida e persistida no log de transações do banco de dados secundário. Contudo, a chamada não aguarda a reprodução (confirmação) das transações transmitidas no secundário. sp_wait_for_database_copy_sync tem escopo para um link de replicação geográfica específico. Qualquer usuário com os direitos de conexão para o banco de dados primário pode chamar este procedimento.

Observação

sp_wait_for_database_copy_sync impede a perda de dados após o failover geográfico para transações específicas, mas não garante a sincronização completa para acesso de leitura. A demora causada por uma chamada de procedimento sp_wait_for_database_copy_sync pode ser significativa e depende do tamanho, no momento da chamada, do log de transações ainda não transmitido no primário.

Alterar a região secundária

Vamos supor que a instância A é a primária, a instância B é a secundária existente e a instância C é a nova instância secundária na terceira região. Para fazer a transição, siga estas etapas:

1. Crie a instância C com o mesmo tamanho de A na mesma zona DNS.
2. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, as tentativas de iniciar sessão começarão a falhar, porque os aliases do SQL para os ouvintes do grupo de failover foram excluídos e o gateway não reconhecerá o nome do grupo de failover. Os bancos de dados secundários serão desconectados dos primários e se tornarão bancos de dados de leitura/gravação.
3. Crie um grupo de failover com o mesmo nome entre a instância A e C. Siga as instruções no guia de configuração do grupo de failover. Essa é uma operação de tamanho de dados e será concluída quando todos os bancos de dados da instância A forem propagados e sincronizados.
4. Exclua a instância B se não for necessária para evitar encargos indevidos.

Observação

Após a etapa 2 e até que a etapa 3 seja concluída, os bancos de dados na instância A permanecerão desprotegidos contra uma falha catastrófica da instância A.

Alterar a região primária

Vamos supor que a instância A é a primária, a instância B é a secundária existente e a instância C é a nova instância primária na terceira região. Para fazer a transição, siga estas etapas:

1. Crie a instância C com o mesmo tamanho de B na mesma zona DNS.
2. Conecte-se à instância B e faça o failover manualmente para alternar a instância primária para B. A instância A se tornará a nova instância secundária de forma automática.
3. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, as tentativas de iniciar sessão usando pontos de extremidade do grupo de failover começarão a falhar. Os bancos de dados secundários em A serão desconectados dos primários e se tornarão bancos de dados de leitura/gravação.
4. Crie um grupo de failover com o mesmo nome entre as instâncias B e C. Siga as instruções descritas no guia do grupo de failover. Essa é uma operação de tamanho de dados e será concluída quando todos os bancos de dados da instância A forem propagados e sincronizados. Tentativas de iniciar sessão deixarão de falhar neste ponto.
5. Failover manual para alternar a instância C para a função primária. A instância B passará a ser a nova instância secundária automaticamente.
6. Exclua a instância A se não for necessária para evitar encargos indevidos.

Cuidado

Após a etapa 3 e até que a etapa 4 seja concluída, os bancos de dados na instância A permanecerão desprotegidos contra uma falha catastrófica da instância A.

Importante

Quando o grupo de failover é excluído, os registros DNS dos pontos de extremidade do ouvinte também são excluídos. Agora, não existe probabilidade de outra pessoa criar um grupo de failover ou um alias de DNS do servidor com o mesmo nome. Como os nomes do grupo de failover devem ser globalmente exclusivos, isso impedirá que você use o mesmo nome novamente. Para minimizar esse risco, não use nomes genéricos em grupos de failover.

Habilitar cenários dependentes de objetos dos bancos de dados do sistema

Os bancos de dados de sistema não são replicados para a instância secundária em um grupo de failover. Para habilitar cenários que dependam de objetos dos bancos de dados do sistema, crie os mesmos objetos na instância secundária e os mantenha sincronizados com a instância primária.

Por exemplo, se você planeja usar os mesmos logons na instância secundária, crie-os com o SID idêntico.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Para saber mais, confira Replicação de logons e trabalhos de agente.

Sincronizar as propriedades da instância e as instâncias de políticas de retenção

As instâncias em um grupo de failover permanecem com recursos do Azure separados, e nenhuma alteração feita à configuração da instância primária será replicada automaticamente para a instância secundária. Execute todas as alterações relevantes na instância primária e na secundária. Por exemplo, se você alterar a redundância de armazenamento de backup ou a política de retenção de backup de longo prazo na instância primária, não deixe de fazer a mesma alteração na instância secundária.

Instâncias de colocação em escala

É possível escalar ou reduzir verticalmente as instâncias primária e secundária para um tamanho da computação diferente na mesma camada de serviço ou em uma camada de serviço diferente. Ao escalar verticalmente dentro da mesma camada de serviço, recomendamos que você primeiro escale verticalmente o secundário geográfico e, em seguida, escale verticalmente o primário. Ao reduzir verticalmente dentro da mesma camada de serviço, inverta a ordem: primeiro reduza verticalmente o primário e, em seguida, reduza verticalmente o secundário. Essa recomendação é aplicada quando a instância é dimensionada para uma camada de serviço diferente.

A sequência é recomendada especificamente para evitar o problema de o banco de dados em área geográfica secundária com uma SKU inferior ter sobrecarga e precisar ser propagado novamente durante um processo de atualização ou de downgrade.

Permissões

As permissões para um grupo de failover são gerenciadas por meio do RBAC (controle de acesso baseado em função) do Azure.

O acesso de gravação do RBAC do Azure é necessário para criar e gerenciar grupos de failover. A função do Colaborador da Instância Gerenciada de SQL tem todas as permissões necessárias para gerenciar grupos de failover.

A tabela a seguir lista escopos de permissão específicos para a Instância Gerenciada de SQL do Azure:

Ação	Permissão	Escopo
Criar grupo de failover	Acesso de gravação do RBAC do Azure	Instância gerenciada secundária de instância gerenciada primária
Atualizar grupo de failover	Acesso de gravação do RBAC do Azure	Grupo de failover todos os bancos de dados dentro da instância gerenciada
Fazer failover de grupo de failover	Acesso de gravação do RBAC do Azure	Grupo de failover em uma nova instância gerenciada primária

Limitações

Esteja ciente das seguintes limitações:

• Os grupos de failover não podem ser criados entre duas instâncias na mesma região do Azure.
• Os grupos de failover não podem ser renomeados. Será necessário excluir o grupo e recriá-lo com outro nome.
• Um grupo de failover contém exatamente duas instâncias gerenciadas. A adição de instâncias extras ao grupo de failover não tem suporte.
• Uma instância pode participar apenas de um grupo de failover a qualquer momento.
• Um grupo de failover não pode ser criado entre duas instâncias que pertencem a locatários diferentes do Azure.
• Um grupo de failover entre duas instâncias que pertencem a assinaturas diferentes do Azure não pode ser criado usando o portal do Azure ou a CLI do Azure. Use o Azure PowerShell ou a API REST para criar esse grupo de failover. Depois de criado, o grupo de failover entre assinaturas fica regularmente visível no portal do Azure e todas as operações subsequentes, incluindo failovers, podem ser inicializadas do portal do Azure ou da CLI do Azure.
• Não há suporte para renomeação de banco de dados em banco de dados no grupo de failover. Você precisará excluir temporariamente o grupo de failover para poder renomear um banco de dados.
• Os bancos de dados do sistema não são replicados para a instância secundária em um grupo de failover. Portanto, os cenários que dependem de objetos dos bancos de dados do sistema, como logons do servidor e cargos do agente exigem que os objetos sejam criados manualmente nas instâncias secundárias e também sejam mantidos manualmente em sincronia após as alterações feitas na instância primária. A única exceção é a SMK (chave mestra de serviço) de Instância Gerenciada de SQL, que é replicada automaticamente na instância secundária durante a criação do grupo de failover. Quaisquer alterações subsequentes do SMK na instância primária, no entanto, não serão replicadas na instância secundária. Para saber mais, veja como Habilitar cenários dependentes de objetos dos bancos de dados do sistema.
• Os grupos de failover não poderão ser criados entre instâncias se qualquer uma delas estiver em um pool de instâncias.

Gerenciar programaticamente grupos de failover

Os grupos de failover também podem ser gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure e a API REST. As tabelas a seguir descrevem o conjunto de comandos disponíveis. Os grupos de failover incluem um conjunto de APIs do Azure Resource Manager para gerenciamento, incluindo a API REST do Banco de Dados SQL do Azure e cmdlets do Azure PowerShell. Essas APIs exigem o uso de grupos de recursos e dão suporte ao RBAC do Azure (controle de acesso baseado em função do Azure). Para obter mais informações sobre como implementar funções de acesso, confira RBAC (controle de acesso baseado em função) do Azure.

PowerShell

Cmdlet	Descrição
New-AzSqlDatabaseInstanceFailoverGroup	Esse comando cria e registra um grupo de failover nas instâncias primária e secundária
Set-AzSqlDatabaseInstanceFailoverGroup	Modifica a configuração de um grupo de failover
Get-AzSqlDatabaseInstanceFailoverGroup	Recupera a configuração de um grupo de failover
Switch-AzSqlDatabaseInstanceFailoverGroup	Dispara o failover de um grupo de failover para a instância secundária
Remove-AzSqlDatabaseInstanceFailoverGroup	Remove um grupo de failover

CLI do Azure

Comando	Descrição
az sql instance-failover-group create	Esse comando cria um grupo de failover e registra-o nos servidores primário e secundário
az sql instance-failover-group delete	Remove o grupo de failover do servidor
az sql instance-failover-group show	Recupera a configuração de um grupo de failover
az sql instance-failover-group update	Modifica a configuração do grupo de failover e/ou adiciona um ou mais bancos de dados a um grupo de failover
az sql instance-failover-group set-primary	Dispara o failover de um grupo de failover para o servidor secundário

REST API

API	Descrição
Criar ou atualizar grupo de failover	Cria ou atualiza a configuração de um grupo de failover
Excluir grupo de failover	Remove o grupo de failover da instância
Failover (planejado)	Dispara o failover da instância primária atual para esta instância com sincronização de dados completa.
O Failover forçado permite a perda de dados	Dispara o failover da instância primária atual para a instância secundária sem sincronização de dados. Essa operação pode resultar em perda de dados.
Obter grupo de failover	recupera a configuração de um grupo de failover.
Listar grupos de failover – listar por localização	Lista os grupos de failover em uma localização.

Próximas etapas

Para as etapas da configuração de um grupo de failover, confira o guia Adicionar uma instância gerenciada a um grupo de failover.

Para ter uma visão geral do recurso, confira Grupos de failover. Para saber como economizar nos custos de licenciamento, confira Configurar uma réplica em espera.