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

Artigo
08/19/2024

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

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

Para obter um script do PowerShell de ponta a ponta que cria ambas as instâncias em um grupo de failover, faça a revisão de Add instance to a failover group with PowerShell.

Pré-requisitos

Para configurar um grupo de failover, você já deve ter uma instância gerenciada de SQL que pretende usar como a instância primária. Para obter uma introdução, faça a revisão de Create instance.

Requisitos de configuração

Para configurar um grupo de failover entre uma Instância Gerenciada de SQL primária e secundária, considere os requisitos apresentados a seguir:

A instância gerenciada secundária deve estar vazia, sem nenhum banco de dados de usuário.
As duas instâncias precisam estar na mesma camada de serviço e ter um tamanho do armazenamento semelhante. Embora não seja um requisito, nossa recomendação é para que ambas as instâncias tenham um tamanho da computação equivalente com a finalidade de garantir que a instância secundária possa realizar o processamento das alterações replicadas da instância primária de forma sustentável, especialmente durante períodos de maior demanda de atividade.
O intervalo de endereços IP para a rede virtual da instância primária não deve realizar uma sobreposição ao intervalo de endereços da rede virtual para a instância gerenciada secundária ou de qualquer outra rede virtual que tenha emparelhamento com a rede virtual primária ou secundária.
Ambas as instâncias devem estar na mesma zona DNS. Ao criar a instância gerenciada secundária, é necessário especificar a ID da zona DNS da instância primária. Caso contrário, a ID da zona será gerada como uma sequência aleatória quando a primeira instância for criada em cada rede virtual, e uma ID semelhante será atribuída para todas as outras instâncias na mesma sub-rede. Uma vez atribuída, a zona DNS não pode ser modificada.
As regras dos Grupos de Segurança de Rede (NSG) para as sub-redes de ambas as instâncias devem permitir conexões TCP de entrada e de saída abertas para a porta 5022 e para o intervalo de portas 11000 a 11999, a fim de facilitar a comunicação entre as duas instâncias.
As instâncias gerenciadas devem ser implantadas em regiões emparelhadas por motivos de desempenho. As instâncias gerenciadas localizadas em regiões com emparelhamento geográfico se beneficiam de uma velocidade de replicação geográfica significativamente maior em comparação com regiões não emparelhadas.
Ambas as instâncias devem usar a mesma política de atualizações.

Criação da instância secundária

Ao criar a instância secundária, você deve usar uma rede virtual que tenha um espaço de endereços IP que não realize uma sobreposição ao intervalo de espaço de endereços IP da instância primária. Além disso, ao configurar a nova instância secundária, é necessário especificar a ID da zona da instância primária.

É possível configurar a rede virtual secundária e criar a instância secundária ao usar o portal do Azure e o PowerShell.

Azure portal
PowerShell

Criar rede virtual

Para criar uma rede virtual para a instância secundária no portal do Azure, siga estas etapas:

Verifique o espaço de endereço da instância primária. Navegue até o recurso de rede virtual da instância primária no portal do Azure e, em Configurações, faça a seleção de Espaço de endereço. Verifique o intervalo em Intervalo de endereços:
Crie uma nova rede virtual que você planeja usar para a instância secundária ao acessar a página Criar rede virtual.
Na guia Básico da página Criar rede virtual:
1. Selecione o Grupo de Recursos que você pretende usar para a instância secundária. Crie um novo caso esse grupo ainda não exista.
2. Forneça um nome para a sua rede virtual, como vnet-sql-mi-secondary.
3. Selecione uma região que esteja emparelhada com a região na qual está a instância primária.
Na guia Endereços IP da página Criar rede virtual:
1. Use Excluir espaço de endereço para excluir o espaço de endereço IPv4 existente.
2. Após excluir o espaço de endereços, selecione Adicionar espaço de endereço IPv4 para adicionar um novo espaço e, em seguida, forneça um espaço de endereços IP que seja diferente do espaço de endereço usado pela rede virtual da instância primária. Por exemplo, se a instância primária atual usar um espaço de endereço 10.0.0.16, insira 10.1.0.0/16 para o espaço de endereço da rede virtual que você pretende usar para a instância secundária.
3. Use + Adicionar uma sub-rede para adicionar uma sub-rede padrão com valores padrão.
4. Use + Adicionar uma sub-rede para adicionar uma sub-rede vazia com o nome ManagedInstance, que será dedicada à instância secundária, usando um intervalo de endereços diferente do usado para a sub-rede padrão. Por exemplo, se sua instância primária usar um intervalo de endereços de 10.0.0.0 a 10.0.255.255, forneça um intervalo de sub-rede de 10.1.1.0 - 10.1.1.255 para a sub-rede da instância secundária.
Use Revisão + Criação para revisar as configurações e, em seguida, clique em Criar para criar a nova rede virtual.

Criação da instância secundária

Após a configuração da sua rede virtual, siga estas etapas para criar sua instância secundária no portal do Azure:

Acesse a página Criar Instância Gerenciada de SQL do Azure no portal do Azure.
Na guia Informações básicas da página Criar Instância Gerenciada de SQL do Azure:
1. Escolha uma região para a instância secundária que esteja emparelhada com a instância primária.
2. Escolha uma camada de serviço que corresponda à camada de serviço da instância primária.
Na guia Sistema de Rede da página Criar Instância Gerenciada de SQL do Azure, use a lista suspensa em Rede virtual / sub-rede para selecionar a rede virtual e a sub-rede que você criou anteriormente:
Na guia Configurações adicionais da página Criar Instância Gerenciada de SQL do Azure, selecione Sim para Usar como instância secundária de failover e, em seguida, escolha a instância primária apropriada na lista suspensa.
Configure o restante da instância de acordo com suas necessidades de negócios e, em seguida, crie-a ao usar Revisão + Criação.

Você pode criar tanto a rede virtual quanto a instância secundária ao usar o PowerShell. Para obter uma amostra completa de script do PowerShell que realiza ambas as tarefas, faça a revisão de Add instance to failover group with PowerShell.

Ao criar a instância secundária com o Azure PowerShell, certifique-se de especificar o valor DnsZonePartner com a ID da 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

Estabelecimento de conectividade entre as instâncias

Para garantir um fluxo ininterrupto de tráfego de replicação geográfica, você deve estabelecer conectividade entre as sub-redes da rede virtual que hospeda as instâncias primária e secundária. Existem diversas maneiras de realizar a conexão entre instâncias gerenciadas em diferentes regiões do Azure, incluindo:

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 global disponibiliza uma conexão privada de baixa latência e alta Bandwidth entre as redes virtuais emparelhadas ao usar a infraestrutura de backbone da Microsoft. A Internet pública, os gateways ou a criptografia adicional não é necessária na comunicação entre as redes virtuais emparelhadas.

Importante

Métodos alternativos de conexão de instâncias que envolvem dispositivos de sistema de rede adicionais podem complicar a solução de problemas de conectividade ou de velocidade de duplicação, possivelmente exigindo a participação ativa de administradores de rede e, potencialmente, prolongando significativamente o tempo de resolução.

Se você usar um mecanismo distinto do emparelhamento de rede virtual global recomendado para estabelecer a conectividade entre as instâncias, certifique-se de que:

Dispositivos de sistema de rede, como firewalls ou dispositivos virtuais de rede (NVAs), não bloqueiam o tráfego nas conexões de entrada e de saída para a porta 5022 (TCP) e para o intervalo de portas 11000 a 11999.
O roteamento está configurado corretamente, e o roteamento assimétrico é evitado.
Se você implantar grupos de failover em uma topologia de rede em hub e spoke entre regiões, para evitar problemas de conectividade e velocidade de duplicação, o tráfego de duplicação deve ser enviado diretamente entre as duas sub-redes de instâncias gerenciadas, em vez de ser direcionado por meio de redes de hub.

Este artigo orienta você a configurar o emparelhamento de rede virtual global entre as redes das duas instâncias ao usar o portal do Azure e o PowerShell.

Azure portal
PowerShell

No portal do Azure, acesse o recurso Rede virtual da instância gerenciada primária.
Selecione Emparelhamentos em Configurações para abrir a página de Emparelhamentos e, em seguida, use + Adicionar na barra de comandos para abrir a página Adicionar emparelhamento.

Na página Adicionar emparelhamento, insira ou selecione os valores para as configurações apresentadas a seguir:

Configurações	Descrição
Resumo da rede virtual remota
Nome do link de emparelhamento	o nome para o emparelhamento deve ser exclusivo na rede virtual. Este artigo usa `Fog-peering`.
Modelo de implantação de rede virtual	Selecione Gerenciador de recursos.
Conheço minha ID do recurso	Você pode deixar esta caixa desmarcada, a menos que saiba a ID do recurso.
Assinatura	Selecione a assinatura na lista suspensa.
Rede virtual	Selecione a rede virtual para a instância secundária na lista suspensa.
Configurações do emparelhamento da rede virtual remota
Permitir que a “rede virtual secundária” obtenha acesso à “rede virtual primária”	Marque a caixa para permitir a comunicação entre as duas redes. 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.
Permitir que a “rede virtual secundária” receba tráfego encaminhado proveniente da “rede virtual primária”	Você pode marcar ou desmarcar esta caixa, qualquer uma dessas opções funciona para este guia. Para saber mais, confira Criar um emparelhamento.
Permitir que o gateway ou que o servidor de rota na “rede virtual secundária” encaminhe o tráfego para a “rede virtual primária”	Você pode marcar ou desmarcar esta caixa, qualquer uma dessas opções funciona para este guia. Para saber mais, confira Criar um emparelhamento.
Habilitar a “rede virtual secundária” para usar o gateway remoto ou o servidor de rota da “rede virtual primária”	Deixe esta caixa desmarcada. Para obter mais informações sobre as outras opções disponíveis, confira Criar um emparelhamento.
Resumo da rede virtual local
Nome do link de emparelhamento	O nome semelhante ao do emparelhamento usado para a rede virtual remota. Este artigo usa `Fog-peering`.
Permitir que a “rede virtual primária” obtenha acesso à “rede virtual secundária”	Marque a caixa para permitir a comunicação entre as duas redes. 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.
Permitir que a “rede virtual primária” receba tráfego encaminhado proveniente da “rede virtual secundária”	Você pode marcar ou desmarcar esta caixa, qualquer uma dessas opções funciona para este guia. Para saber mais, confira Criar um emparelhamento.
Permitir que o gateway ou que o servidor de rota na “rede virtual primária” encaminhe o tráfego para a “rede virtual secundária”	Você pode marcar ou desmarcar esta caixa, qualquer uma dessas opções funciona para este guia. Para saber mais, confira Criar um emparelhamento.
Habilitar a “rede virtual primária” para usar o gateway remoto ou o servidor de rota da “rede virtual secundária”	Deixe esta caixa desmarcada. Para obter mais informações sobre as outras opções disponíveis, confira Criar um emparelhamento.

Use a opção Adicionar para configurar o emparelhamento com a rede virtual selecionada e navegar automaticamente para a página de Emparelhamentos, que mostra que as duas redes estão conectadas:

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.

Configuração das portas e das regras do NSG

Independentemente do mecanismo de conectividade escolhido entre as duas instâncias, suas redes devem atender aos requisitos apresentados a seguir para o fluxo de tráfego de replicação geográfica:

A tabela de rotas e os grupos de segurança de rede atribuídos às sub-redes da instância gerenciada não são compartilhados entre as duas redes virtuais emparelhadas.
As regras do Grupo de Segurança de Rede (NSG) em ambas as sub-redes que hospedam cada instância permitem tanto o tráfego de entrada quanto o de saída para a outra instância na porta 5022 e no intervalo de portas de 11000 a 11999.

É possível configurar a comunicação de portas e as regras do NSG ao usar o portal do Azure e o PowerShell.

Azure portal
PowerShell

Para abrir as portas do Grupo de Segurança de Rede (NSG) no portal do Azure, siga estas etapas:

Acesse o recurso do grupo de segurança de rede para a instância primária.
Em Configurações, selecione Regras de segurança de entrada. Verifique se você já tem regras que permitam o tráfego para a porta 5022 e para o intervalo de 11000 a 11999. Se essas regras já existirem e a origem atender às suas necessidades de negócios, você pode ignorar esta etapa. Caso as regras não existam, ou se você desejar usar uma origem diferente (como um endereço IP mais seguro), exclua a regra existente e selecione + Adicionar na barra de comandos para abrir a página Adicionar regra de segurança de entrada:

Na página Adicionar regra de segurança de entrada, insira ou faça a seleção dos valores para as configurações apresentadas a seguir:

Configurações	Valor recomendado	Descrição
Origem	Endereços IP ou Marca de Serviço	O filtro para a origem da comunicação. O endereço IP é a opção mais segura e recomendada para ambientes de produção. A marca de serviço é a opção mais apropriada para ambientes que não são de produção.
Marca de serviço de origem	Se você fez a seleção de Marca de Serviço como a origem, forneça `VirtualNetwork` como a marca de origem.	As marcas padrão são identificadores definidos previamente que representam uma categoria de endereços IP. A marca VirtualNetwork denota todos os espaços de endereços de rede virtual e local.
Endereços IP da fonte	Se você fez a seleção de Endereços IP como a origem, forneça o endereço IP da instância secundária.	Forneça um intervalo de endereços ao usar a notação CIDR (por exemplo, 192.168.99.0/24 ou 2001:1234::/64), ou um endereço IP (por exemplo, 192.168.99.0 ou 2001:1234::). Você também pode fornecer uma lista separada por vírgula de endereços IP ou intervalos de endereços ao usar IPv4 ou IPv6.
Intervalos de portas de origem	5022	Isso especifica em quais portas o tráfego será permitido por esta regra.
Serviço	Personalizado	O serviço especifica o protocolo de destino e o intervalo de portas dessa regra.
Intervalos de portas de destino	5022	Isso especifica em quais portas o tráfego será permitido por esta regra. Essa porta deve corresponder ao intervalo de portas de origem.
Ação	Allow	Permite a comunicação na porta especificada.
Protocolo	TCP	Determina o protocolo para a comunicação usando a porta.
Prioridade	1200	As regras são processadas em ordem de prioridade. Quanto menor o número, maior a prioridade.
Nome	allow_geodr_inbound	O nome da regra.
Descrição	Opcional	Você pode escolher fornecer uma descrição ou deixar este campo em branco.

Selecione Adicionar para salvar as configurações e adicionar a nova regra.

Repita essas etapas para adicionar outra regra de segurança de entrada para o intervalo de portas de 11000-11999 com um nome como allow_redirect_inbound e uma prioridade um pouco superior à regra de 5022, como 1100.
Em Configurações, escolha Regras de segurança de saída. Verifique se você já tem regras que permitam o tráfego para a porta 5022 e para o intervalo de 11000 a 11999. Se essas regras já existirem e a origem atender às suas necessidades de negócios, você pode ignorar esta etapa. Caso as regras não existam, ou se você desejar usar uma origem diferente (como um endereço IP mais seguro), exclua a regra existente e selecione + Adicionar na barra de comandos para abrir a página Adicionar regra de segurança de saída.
Na página Adicionar regra de segurança de saída, use a mesma configuração para a porta 5022 e o intervalo de 11000-11999 que você usou para as portas de entrada.
Acesse o grupo de segurança de rede da instância secundária e repita essas etapas para que ambos os grupos de segurança de rede tenham as regras apresentadas a seguir:
- Permitir tráfego de entrada na porta 5022
- Permitir tráfego de entrada no intervalo de portas de 11000-11999
- Permitir tráfego de saída na porta 5022
- Permitir tráfego de saída no intervalo de portas de 11000-11999

Criar o grupo de failover

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

Portal
PowerShell

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

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.
Selecione a instância gerenciada primária que você deseja adicionar ao grupo de failover.
Em Gerenciamento de Dados, selecione Grupos de failover e, em seguida, use Adicionar grupo para abrir a página Grupo de Failover da Instância:
Na página Grupo de Failover da Instância:
1. A Instância gerenciada primária está selecionada previamente.
2. Em Nome de grupo de failover, insira um nome para o grupo de failover.
3. Em Instância gerenciada secundária, selecione a instância gerenciada que você deseja usar como secundária no grupo de failover.
4. Escolha uma Política de failover de leitura/gravação na lista suspensa. Nossa recomendação é para escolher Manual a fim de fornecer a você controle sobre o failover.
5. Deixe Habilitar direitos de failover em Desativado, a menos que você pretenda usar esta réplica somente para recuperação de desastre.
6. Use Criar para salvar suas configurações e criar seu grupo de failover.
Após o início da implantação do grupo de failover, você será redirecionado para a página Grupos de failover. A página será atualizada para mostrar o novo grupo de failover assim que a implantação for concluída.

Use o comando New-AzSqlDatabaseInstanceFailoverGroup para criar o grupo de failover para as instâncias gerenciadas ao usar 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

Testar failover

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

Observação

Se as instâncias estiverem em assinaturas ou grupos de recursos diferentes, inicie o failover usando a instância secundária.

Azure portal
PowerShell

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

Acesse a instância gerenciada primária ou secundária no portal do Azure.
Em Gerenciamento de dados selecione Grupos de failover.
Na página Grupos de failover, observe qual instância é a primária e qual é a secundária.
Na página Grupos de failover, selecione Failover na barra de comandos. Selecione Sim na mensagem de aviso sobre a desconexão das sessões TDS e tome nota das implicações de licenciamento.
Na página Grupos de failover, após o failover ser bem-sucedido, as instâncias realizam a comutação de funções, de modo que a instância anteriormente secundária se torna a nova instância primária e a instância anteriormente primária se torna a nova instância secundária.

Importante

Se não ocorrer a comutação de funções, 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.
(Opcional) Na página Grupos de failover, use Failover para realizar a comutação de funções, de modo que a instância primária original se torne primária novamente.

Teste o failover planejado ao fazer failover para a réplica secundária com o PowerShell e, em seguida, faça o failback.

Verificar as funções de cada instância

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


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

Fazer failover para a instância secundária

Use o comando Switch-AzSqlDatabaseFailoverGroup para fazer failover para a instância secundária.

# 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

Verificar as funções de cada instância

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


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

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

Opcionalmente, use o comando Switch-AzSqlDatabaseFailoverGroup para reverter o failover para a instância primária.


# 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

Localizar ponto de extremidade do ouvinte

Após configurar o grupo de failover, faça a atualização da cadeia de conexão do seu aplicativo para direcionar para o ponto de extremidade de leitura/gravação do ouvinte, garantindo que o aplicativo continue em conexão com a instância primária após um evento de failover. Ao usar o ponto de extremidade do ouvinte, você não precisa atualizar a cadeia de conexão de forma manual toda vez que o grupo de failover fizer failover, já que o tráfego é sempre encaminhado para o grupo primário atual. Além disso, é possível direcionar uma carga de trabalho somente leitura para o ponto de extremidade de somente leitura do ouvinte.

Para localizar o ponto de extremidade do ouvinte no portal do Azure, acesse a instância gerenciada de SQL e, em Gerenciamento de dados, selecione Grupos de failover.

Role a página para baixo para encontrar os pontos de extremidade do ouvinte:

O ponto de extremidade de leitura/gravação do ouvinte, no formato fog-name.dns-zone.database.windows.net, encaminha o tráfego para a instância primária.
O ponto de extremidade de somente leitura do ouvinte, no formato fog-name.dns-zone.tutorial.database.windows.net, encaminha o tráfego para a instância secundária.

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 oferece suporte para criar grupos de failover entre diferentes assinaturas.

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:

Crie a instância C com o mesmo tamanho de A na mesma zona DNS.
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.
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.
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:

Crie a instância C com o mesmo tamanho de B na mesma zona DNS.
Inicie um failover manual da instância B para que ela se torne a nova instância primária. A instância A se torna automaticamente a nova instância secundária.
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.
Crie um grupo de failover com o mesmo nome entre as instâncias B e C. Esta é uma operação de tamanho de dados e será concluída quando todos os bancos de dados da instância B forem propagados e sincronizados com a instância C. Nesse momento, as tentativas de iniciar sessão deixarão de falhar.
Faça um failover manual para realizar a comutação da instância C para a função de primária. A instância B passará a ser a nova instância secundária automaticamente.
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.

Alterar política de atualização

As instâncias de um grupo de failover devem ter políticas de atualização correspondentes. Para habilitar a política de atualizações Sempre atualizado em instâncias que fazem parte de um grupo de failover, primeiro habilite a política de atualizações Sempre atualizado na instância secundária, aguarde a alteração entrar em vigor e, em seguida, atualize a política para a instância primária.

Embora a alteração da política de atualização na instância primária no grupo de failover faça com que a instância faça failover para outro nó local (de modo semelhante às operações de gerenciamento em instâncias que não fazem parte de um grupo de failover), isso não faz com que o grupo de failover realize failover, mantendo a instância primária na função primária.

Cuidado

Depois que a política atualizada for alterada para Sempre atualizado, não será mais possível revertê-la para a política de atualizações do SQL Server 2022.

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, 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. Siga a mesma sequência ao escalar uma instância para uma camada de serviço diferente.

Essa sequência é recomendada para evitar problemas de sobrecarga da geo-secundária, em uma SKU mais baixa, e a necessidade de fazer o reseed durante um processo de upgrade ou 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.

A função de Colaborador de Instância Gerenciada de SQL, com escopo nos grupos de recursos da instância gerenciada primária e secundária, é suficiente para executar todas as operações de gerenciamento em grupos de failover.

A tabela a seguir fornece uma exibição granular das permissões mínimas necessárias e seus respectivos níveis mínimos de escopo necessários para operações de gerenciamento em grupos de failover:

Operação de gerenciamento	Permissão	Escopo
Criar/atualizar grupo de failover	`Microsoft.Sql/locations/instanceFailoverGroups/write`	Grupos de recursos de instância gerenciada primária e secundária
Criar/atualizar grupo de failover	`Microsoft.Sql/managedInstances/write`	Instância gerenciada primária e secundária
Fazer failover de grupo de failover	`Microsoft.Sql/locations/instanceFailoverGroups/failover/action`	Grupos de recursos de instância gerenciada primária e secundária
Forçar failover de grupo de failover	`Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action`	Grupos de recursos de instância gerenciada primária e secundária
Excluir grupo de failover	`Microsoft.Sql/locations/instanceFailoverGroups/delete`	Grupos de recursos de instância gerenciada primária e secundá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.
A criação de um grupo de failover entre duas instâncias em diferentes grupos de recursos ou assinaturas tem suporte somente por parte do Azure PowerShell ou da API REST, e não pelo portal do Azure ou pela CLI do Azure. Após a criação do grupo de failover, ele será visível no portal do Azure, e todas as operações tem suporte para serem executadas tanto no portal quanto com a CLI do Azure. O failover deve ser iniciado usando a instância secundária.
No momento, não há suporte para a criação de um grupo de failover com uma instância configurada com um link de instância gerenciada.
Não há suporte para renomeação de banco de dados em banco de dados no grupo de failover. Para renomear um banco de dados, será necessário excluir temporariamente o grupo de failover.
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.
Para instâncias dentro de um grupo de failover, a alteração da camada de serviço para, ou a partir, da camada de Uso Geral da Próxima Geração não tem suporte. Primeiro, você deve excluir o grupo de failover antes de modificar qualquer réplica e, em seguida, recriar o grupo de failover depois que a alteração entrar em vigor.
As instâncias gerenciadas de SQL em um grupo de failover devem ter a mesma política de atualização, embora seja possível alterar a política de atualização para instâncias em um grupo de failover.

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.

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

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

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.

Compartilhar via

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

Pré-requisitos

Requisitos de configuração

Criação da instância secundária

Criar rede virtual

Criação da instância secundária

Estabelecimento de conectividade entre as instâncias

Configuração das portas e das regras do NSG

Criar o grupo de failover

Testar failover

Verificar as funções de cada instância

Fazer failover para a instância secundária

Verificar as funções de cada instância

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

Localizar ponto de extremidade do ouvinte

Criar um grupo entre instâncias em assinaturas diferentes

Evitar a perda de dados críticos

Alterar a região secundária

Alterar a região primária

Alterar política de atualização

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

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

Instâncias de colocação em escala

Permissões

Limitações

Gerenciar programaticamente grupos de failover

Comentários

Recursos adicionais

Compartilhar via

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

Pré-requisitos

Requisitos de configuração

Criação da instância secundária

Criar rede virtual

Criação da instância secundária

Estabelecimento de conectividade entre as instâncias

Configuração das portas e das regras do NSG

Criar o grupo de failover

Testar failover

Localizar ponto de extremidade do ouvinte

Criar um grupo entre instâncias em assinaturas diferentes

Evitar a perda de dados críticos

Alterar a região secundária

Alterar a região primária

Alterar política de atualização

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

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

Instâncias de colocação em escala

Permissões

Limitações

Gerenciar programaticamente grupos de failover

Conteúdo relacionado

Comentários

Recursos adicionais