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

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

• Base de Dados SQL do Azure
• Instância Gerida do SQL no Azure

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

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

Pré-requisitos

Considere os seguintes pré-requisitos:

• A instância gerenciada secundária deve estar vazia, ou seja, não conter bancos de dados de usuários.
• As duas instâncias do SQL Managed Instance têm de estar no mesmo escalão de serviço e ter o mesmo tamanho de armazenamento. Embora não seja necessário, é altamente recomendável que duas instâncias tenham o mesmo tamanho de computação, para garantir que a instância secundária possa processar de forma sustentável as alterações que estão sendo replicadas da instância primária, incluindo os períodos de pico de atividade.
• O intervalo de endereços IP da rede virtual da instância primária não deve se sobrepor ao intervalo de endereços da rede virtual da instância gerenciada secundária ou a 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 DnsZonePartner parâmetro. Se você não especificar um valor para DnsZonePartner, o ID da zona será gerado como uma cadeia de caracteres aleatória quando a primeira instância for criada em cada rede virtual e o mesmo ID for atribuído a todas as outras instâncias na mesma sub-rede. Depois de atribuída, a zona DNS não pode ser modificada.
• As regras NSG (Network Security Groups) na instância de hospedagem de sub-rede devem ter a porta 5022 (TCP) e o intervalo de portas 11000-11999 (TCP) abertos, entrada e saída para conexões de e para a sub-rede que hospeda a outra instância gerenciada. Isso se aplica a ambas as sub-redes, hospedando instâncias primárias e secundárias.
• O agrupamento e o fuso horário da instância gerenciada secundária devem corresponder aos 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 residem em regiões emparelhadas geograficamente se beneficiam de uma velocidade de replicação geográfica significativamente maior em comparação com regiões não emparelhadas.

Intervalo de espaço de endereçamento

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 de zona da instância primária

Ao criar sua instância secundária, você deve especificar o ID da zona da instância primária como .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 secundária de failover 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 o DnsZonePartner parâmetro com 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 DnsZonePartner parâmetro 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."

Habilitando 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 deve ser estabelecida para um fluxo de tráfego de replicação geográfica ininterrupto. Há várias maneiras de estabelecer conectividade entre instâncias gerenciadas em diferentes regiões do Azure, incluindo:

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

O emparelhamento de rede virtual global é recomendado como a maneira mais eficiente e robusta de estabelecer conectividade entre instâncias em um grupo de failover. O emparelhamento de rede virtual global 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. Nenhuma Internet pública, gateways ou criptografia adicional é necessária na comunicação entre as redes virtuais emparelhadas.

Importante

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

Independentemente do mecanismo de conectividade, existem requisitos que têm de ser cumpridos para que o tráfego de georreplicação 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 NSG (Network Security Group) na sub-rede que hospeda a instância principal permitem:
  • Tráfego de entrada na porta 5022 e intervalo de portas 11000-11999 da sub-rede que hospeda a instância secundária.
  • Tráfego de saída na porta 5022 e intervalo de portas 11000-11999 para a sub-rede que hospeda a instância secundária.
• As regras do NSG (Network Security Group) na sub-rede que hospeda a instância secundária permitem:
  • Tráfego de entrada na porta 5022 e intervalo de portas 11000-11999 da sub-rede que hospeda a instância primária.
  • Tráfego de saída na porta 5022 e intervalo de portas 11000-11999 para a sub-rede que hospeda a instância primária.
• Os intervalos de endereços IP de VNets que hospedam instâncias primárias e secundárias não devem se sobrepor.
• Não há sobreposição indireta de intervalos de endereços IP entre as VNets que hospedam a instância primária e secundária, ou 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 outros mecanismos para fornecer conectividade entre as instâncias além do emparelhamento de rede virtual global recomendado , precisará garantir o seguinte:

• Qualquer dispositivo de rede usado, como firewalls ou dispositivos virtuais de rede (NVAs), não bloqueie o tráfego nas portas mencionadas anteriormente.
• O encaminhamento está corretamente configurado e se o encaminhamento assimétrico é evitado.
• Se você implantar grupos de failover em uma topologia de rede hub-and-spoke entre regiões, o tráfego de replicação deverá ir diretamente entre as duas sub-redes de instância gerenciada em vez de ser direcionado pelas redes de hub. Ele ajuda a evitar problemas de conectividade e velocidade de replicação.

Portal

1. No portal do Azure, vá para o recurso de rede virtual para sua instância gerenciada principal.
2. Selecione Emparelhamento em Configurações e, em seguida, selecione + Adicionar.

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

   Administração	Descrição
   Esta rede virtual
   Nome do link de emparelhamento	O nome para o emparelhamento deve ser exclusivo dentro da rede virtual.
   Tráfego para rede virtual remota	Selecione Permitir (padrão) para habilitar a comunicação entre as duas redes virtuais por meio do fluxo padrão VirtualNetwork . A habilitação da comunicação entre redes virtuais permite que os recursos conectados a qualquer rede virtual se comuniquem entre si com a mesma largura de banda e latência como se estivessem conectados à mesma rede virtual. Toda a comunicação entre recursos nas duas redes virtuais é feita através da rede privada do Azure.
   Tráfego encaminhado da rede virtual remota	As opções Permitido (padrão) e Bloquear funcionarão para este tutorial. Para obter mais informações, consulte Criar um emparelhamento
   Gateway de rede virtual ou Servidor de Rotas	Selecione Nenhuma. Para obter mais informações sobre as outras opções disponíveis, consulte Criar um emparelhamento.
   Rede virtual remota
   Nome do link de emparelhamento	O nome do mesmo emparelhamento a ser usado na instância secundária de hospedagem de rede virtual.
   Modelo de implantação de rede virtual	Selecione Gerenciador de recursos.
   Sei o meu ID de recurso	Deixe esta caixa de seleção desmarcada.
   Subscrição	Selecione a assinatura do Azure da rede virtual que hospeda a instância secundária com a qual você deseja emparelhar.
   Rede virtual	Selecione a rede virtual que hospeda a instância secundária com a qual você deseja emparelhar. Se a rede virtual estiver listada, mas esmaecida, pode ser porque o espaço de endereço para a rede virtual se sobrepõe ao espaço de endereço para essa rede virtual. Se os espaços de endereço de rede virtual se sobrepuuserem, eles não poderão ser emparelhados.
   Tráfego para rede virtual remota	Selecione Permitir (padrão)
   Tráfego encaminhado da rede virtual remota	As opções Permitido (padrão) e Bloquear funcionarão para este tutorial. Para obter mais informações, consulte Criar um emparelhamento.
   Gateway de rede virtual ou Servidor de Rotas	Selecione Nenhuma. Para obter mais informações sobre as outras opções disponíveis, consulte Criar um emparelhamento.

2. Selecione Adicionar para configurar o emparelhamento com a rede virtual selecionada. Após alguns segundos, selecione o botão Atualizar e o status de emparelhamento mudará de Atualização para Conectado.

   

PowerShell

Configure o emparelhamento de rede virtual global entre as redes virtuais 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

Este trecho de código usa os seguintes comandos:

Comando	Notas
1. Get-AzVirtualNetwork	Obtém uma rede virtual num 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 suas instâncias gerenciadas usando o portal do Azure ou o PowerShell.

Portal

Crie o grupo de failover para suas Instâncias Gerenciadas SQL usando o portal do Azure.

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

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

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

   

4. Na página Grupo de Failover de Instância, digite o nome do seu grupo de failover e escolha a instância gerenciada secundária na lista suspensa. Selecione Criar para criar o grupo de ativação pós-falha.

   

5. Quando a implantação do grupo de failover estiver concluída, você será levado de volta para a 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

Ativação pós-falha de teste

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

Portal

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

1. Navegue até sua instância gerenciada secundária no portal do Azure e selecione Grupos de Failover de Instância em configurações.

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

3. Selecione Failover e, em seguida, selecione Sim no aviso sobre sessões TDS sendo desconectadas.

   

4. Observe as instâncias gerenciadas na função primária e na secundária. Se o failover for bem-sucedido, as duas instâncias deverão ter trocado de função.

   

Importante

Se as funções não mudarem, verifique a conectividade entre as instâncias e as regras relacionadas de NSG e firewall. Prossiga com a próxima etapa somente depois que as funções mudarem.

1. Vá para a nova instância gerenciada secundária e selecione Failover mais uma vez para falhar a instância primária de volta à função principal.

PowerShell

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

Verifique 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

Failover para o 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 failover para o 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

Verifique 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

Failover para o 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 failover para o 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 o ponto final do serviço de escuta

Depois que o grupo de failover estiver configurado, atualize a cadeia de conexão do seu aplicativo para o ponto de extremidade do ouvinte. Ele mantém seu aplicativo conectado ao ouvinte do grupo de failover, em vez do banco de dados primário, pool elástico ou banco de dados de instância. Dessa forma, você não precisa atualizar manualmente a cadeia de conexão sempre que a entidade do banco de dados fizer failover e o tráfego será roteado para qualquer entidade que seja principal no momento.

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

Criar grupo entre instâncias em assinaturas diferentes

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

• Ao usar a API do PowerShell, você pode fazer isso especificando o PartnerSubscriptionId parâmetro para a Instância Gerenciada SQL secundária.
• Ao usar a API REST, cada ID de instância incluído no parâmetro pode ter sua própria ID de properties.managedInstancePairs assinatura.
• O portal do Azure não suporta a criação de grupos de ativação pós-falha em subscrições diferentes.

Importante

O portal do Azure não dá suporte à criação de grupos de failover em diferentes assinaturas. Para 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 a partir da instância gerenciada SQL primária. Em vez disso, inicie-o na instância de georreplicação secundária.

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. A replicação assíncrona torna inevitável a possibilidade de perda de dados se o primário falhar. Para proteger transações críticas contra perda de dados, um desenvolvedor de aplicativos pode chamar o procedimento armazenado sp_wait_for_database_copy_sync imediatamente após confirmar a transação. A chamada bloqueia o thread de chamada sp_wait_for_database_copy_sync até que a última transação confirmada tenha sido transmitida e reforçada no log de transações do banco de dados secundário. No entanto, não espera que as transações transmitidas sejam repetidas (refeitas) no secundário. sp_wait_for_database_copy_sync tem como escopo um link de replicação geográfica específico. Qualquer usuário com direitos de conexão com o banco de dados primário pode chamar este procedimento.

Nota

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

Alterar a região secundária

Vamos supor que a instância A é a instância primária, a instância B é a instância 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 que A e na mesma zona DNS.
2. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, as tentativas de entrar começam a falhar porque os aliases 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 são desconectados dos primários e se tornam bancos de dados de leitura-gravação.
3. Crie um grupo de failover com o mesmo nome entre as instâncias A e C. Siga as instruções no guia de configuração do grupo de failover. Esta é uma operação de tamanho de dados e é concluída quando todos os bancos de dados da instância A são propagados e sincronizados.
4. Exclua a instância B se não for necessário para evitar cobranças desnecessárias.

Nota

Após a etapa 2 e até que a etapa 3 seja concluída, os bancos de dados da 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 instância primária, a instância B é a instância 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 que B e na mesma zona DNS.
2. Conecte-se à instância B e faça failover manualmente para alternar a instância primária para B. A instância A se torna a nova instância secundária automaticamente.
3. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, as tentativas de entrada usando pontos de extremidade de grupo de failover começam a falhar. Os bancos de dados secundários em A são desconectados dos primários e se tornam 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 no guia do grupo de failover. Esta é uma operação de tamanho de dados e é concluída quando todos os bancos de dados da instância A são propagados e sincronizados. Neste ponto, as tentativas de login param de falhar.
5. Failover manual para alternar a instância C para a função principal. A instância B torna-se a nova instância secundária automaticamente.
6. Exclua a instância A se não for necessário para evitar cobranças desnecessárias.

Atenção

Após a etapa 3 e até que a etapa 4 seja concluída, os bancos de dados da 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. Nesse ponto, há uma probabilidade diferente de zero de outra pessoa criar um grupo de failover com o mesmo nome. Como os nomes de 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 de grupo de failover.

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

As bases de dados do sistema não são replicadas na instância secundária num grupo de ativação pós-falha. Para permitir cenários que dependam de objetos a partir das bases de dados do sistema, certifique-se de criar os mesmos objetos na instância secundária e mantê-los sincronizados com a instância principal.

Por exemplo, se você planeja usar os mesmos logons na instância secundária, certifique-se de criá-los 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, veja Replicação de inícios de sessão e tarefas de agente.

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

As instâncias em um grupo de failover permanecem recursos separados do Azure e nenhuma alteração feita na configuração da instância primária será replicada automaticamente para a instância secundária. Certifique-se de executar todas as alterações relevantes na instância primária e 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 principal, certifique-se de alterá-la também na instância secundária.

Dimensionamento de instâncias

Pode aumentar ou reduzir verticalmente a instância principal e secundária para um tamanho de computação diferente no mesmo escalão de serviço ou para um escalão de serviço diferente. Ao aumentar a escala dentro da mesma camada de serviço, recomendamos que você aumente primeiro a escala do geosecundário e, em seguida, aumente o principal. Ao reduzir a escala dentro da mesma camada de serviço, inverta a ordem: reduza o primário primeiro e, em seguida, diminua o secundário. Quando dimensionar a instância para um escalão de serviço diferente, será aplicada esta recomendação.

A sequência é recomendada especificamente para evitar o problema em que a instância de georreplicação secundária num SKU inferior fica sobrecarregada e tem de ser novamente propagada durante um processo de atualização ou de mudança para uma versão anterior.

Permissões

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

O acesso de gravação do RBAC do Azure é necessário para criar e gerenciar grupos de failover. A função de Colaborador da Instância Gerenciada 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 SQL do Azure:

Ação	Permissão	Scope
Criar o grupo de ativação pós-falha	Acesso de gravação do RBAC do Azure	Instância gerenciada primária Instância gerenciada secundá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
Grupo de failover de failover	Acesso de gravação do RBAC do Azure	Grupo de failover na 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.
• Não é possível mudar o nome dos grupos de ativação pós-falha. Terá de eliminar os grupos e voltar a criá-los com outro nome.
• Um grupo de failover contém exatamente duas instâncias gerenciadas. Não há suporte para a adição de instâncias adicionais ao grupo de failover.
• 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 pertencentes a locatários diferentes do Azure.
• Um grupo de failover entre duas instâncias pertencentes a assinaturas diferentes do Azure não pode ser criado usando o portal do Azure ou a CLI do Azure. Em vez disso, use o Azure PowerShell ou a API REST para criar esse grupo de failover. Uma vez criado, o grupo de failover entre assinaturas é regularmente visível no portal do Azure e todas as operações subsequentes, incluindo failovers, podem ser iniciadas a partir do portal do Azure ou da CLI do Azure.
• Não há suporte para a renomeação de banco de dados para bancos de dados no grupo de failover. Você precisará excluir temporariamente o grupo de failover para poder renomear um banco de dados.
• As bases de dados do sistema não são replicadas na instância secundária num grupo de ativação pós-falha. Portanto, os cenários que dependem de objetos dos bancos de dados do sistema, como logons de servidor e trabalhos de agente, exigem que os objetos sejam criados manualmente nas instâncias secundárias e também mantidos manualmente em sincronia após quaisquer alterações feitas na instância primária. A única exceção é a Chave Mestra de Serviço (SMK) para Instância Gerenciada SQL que é replicada automaticamente para 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 para a instância secundária. Para saber mais, veja como Ativar cenários dependentes de objetos a partir das bases de dados do sistema.
• Os grupos de failover não podem ser criados entre instâncias se qualquer uma delas estiver em um pool de instâncias.

Gerencie grupos de failover programaticamente

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 controle de acesso baseado em função do Azure (Azure RBAC). Para obter mais informações sobre como implementar funções de acesso, consulte Controle de acesso baseado em função do Azure (Azure RBAC).

PowerShell

Cmdlet	Description
New-AzSqlDatabaseInstanceFailoverGroup	Este comando cria um grupo de failover e o registra em instâncias primárias e secundárias
Set-AzSqlDatabaseInstanceFailoverGroup	Modifica a configuração de um grupo de failover
Get-AzSqlDatabaseInstanceFailoverGroup	Recupera a configuração de um grupo de failover
Switch-AzSqlDatabaseInstanceFailoverGroup	Aciona o failover de um grupo de failover para a instância secundária
Remove-AzSqlDatabaseInstanceFailoverGroup	Remove um grupo de failover

CLI do Azure

Comando	Description
az sql instance-failover-group create	Este comando cria um grupo de failover e o registra em servidores primários e secundários
az sql instance-failover-group delete	Remove um grupo de failover do servidor
az sql instance-failover-group show	Recupera uma configuração de grupo de failover
atualização de instância de failover-group do az sql	Modifica a configuração de um grupo de failover e/ou adiciona um ou mais bancos de dados a um grupo de failover
az sql instance-failover-group set-primary	Aciona o failover de um grupo de failover para o servidor secundário

API REST

API	Description
Criar ou atualizar grupo de failover	Cria ou atualiza a configuração de um grupo de failover
Excluir Grupo de Failover	Remove um grupo de failover da instância
Failover (planejado)	Aciona o failover da instância primária atual para essa instância com sincronização total de dados.
Forçar failover permitir perda de dados	Aciona o failover da instância primária atual para a instância secundária sem sincronizar dados. Esta 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 Local	Lista os grupos de failover em um local.

Próximos passos

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

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