Configurar um grupo de failover para Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados 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 bancos de dados individuais e em pool no Banco de Dados SQL do Azure usando o portal do Azure, o Azure PowerShell e a CLI do Azure.

Para scripts de ponta a ponta, examine como adicionar um único banco de dados a um grupo de failover com o Azure PowerShell ou a CLI do Azure.

Pré-requisitos

Considere os seguintes pré-requisitos para criar seu grupo de failover para um banco de dados individual:

• As configurações de logon e firewall do servidor para o servidor secundário precisam corresponder àquelas do servidor primário.

Criar grupo de failover

Portal

Crie o grupo de failover e adicione o banco de dados único a ele 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 marcá-lo como favorito e adicioná-lo como um item no menu de navegação à esquerda.

2. Selecione o banco de dados que você deseja adicionar ao grupo de failover.

3. Selecione o nome do servidor em Nome do servidor para abrir as configurações do servidor.

   

4. Selecione Grupos de failover no painel Configurações e escolha Adicionar grupo para criar um grupo de failover.

   

5. Na página Grupo de Failover, insira ou selecione os valores solicitados e selecione Criar. Crie um novo servidor secundário ou selecione um servidor secundário existente. O servidor secundário no grupo de failover precisa ser configurado em uma região diferente do servidor primário.

   • Bancos de dados dentro do grupo: escolha o banco de dados que deseja adicionar ao grupo de failover. A adição do banco de dados ao grupo de failover iniciará automaticamente o processo de replicação geográfica.

   

PowerShell

Crie o grupo de failover e adicione o banco de dados a ele usando o PowerShell.

Use o New-AzSqlDatabaseFailoverGroup para criar o grupo de failover:

# Create a failover group between the servers
$failovergroup = Write-host "Creating a failover group between the primary and secondary server..."
New-AzSqlDatabaseFailoverGroup `
   –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
$failovergroup

Use os comandos Get-AzSqlDatabase e Add-AzSqlDatabaseToFailoverGroup para adicionar o banco de dados ao grupo de failover:

# Add the database to the failover group
Write-host "Adding the database to the failover group..." 
Get-AzSqlDatabase `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -DatabaseName $databaseName | `
Add-AzSqlDatabaseToFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Successfully added the database to the failover group..."

Observação

É possível implantar seu grupo de failover em assinaturas usando o parâmetro -PartnerSubscriptionId no Azure Powershell começando com Az.SQL 3.11.0. Para saber mais, revise o exemplo a seguir.

CLI do Azure

Nesta etapa, crie o grupo de failover e adiciona o banco de dados a ele usando a CLI do Azure.

Use o az sql failover-group create para criar um grupo de failover e adicionar o banco de dados ao grupo de failover:

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2 --add-db $database

Teste o failover planejado

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

Portal

Teste o failover do grupo de failover 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 marcá-lo como favorito e adicioná-lo como um item no menu de navegação à esquerda.

2. Selecione o banco de dados que você deseja adicionar ao grupo de failover.

   

3. Selecione Grupos de failover no painel Configurações e escolha o grupo de failover recém criado.

   

4. Examine qual servidor é primário e qual é secundário.

5. Selecione Failover no painel de tarefas para fazer failover do grupo de failover que contém o banco de dados.

6. Selecione Sim no aviso que notifica você de que as sessões do TDS serão desconectadas.

   

7. Examine qual servidor agora é primário e qual é secundário. Se o failover tiver sido bem-sucedido, os dois servidores deverão ter trocado as funções.

8. Selecione Failover novamente para faça failover os servidores às funções originais.

PowerShell

Teste o failover do grupo de failover usando o PowerShell.

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

CLI do Azure

Teste o failover usando a CLI do Azure.

Verificar as funções de cada servidor

Use o comando az sql failover-group show para confirmar as funções de cada servidor no grupo de failover.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Fazer failover no servidor secundário

Use o comando az sql failover-group set-primary para fazer failover para o servidor secundário. Use o comando az sql failover-group show para verificar um failover bem-sucedido.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

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

Use o comando az sql failover-group set-primary para fazer failback no servidor primário.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Se for necessário excluir o banco de dados secundário, remova-o do grupo de failover antes de excluí-lo. A exclusão de um banco de dados secundário antes da remoção dele do grupo de failover pode causar um comportamento imprevisível.

Para scripts de ponta a ponta, examine como adicionar um pool elástico a um grupo de failover com o Azure PowerShell ou a CLI do Azure.

Pré-requisitos

Considere os seguintes pré-requisitos para criar seu grupo de failover para um banco de dados em pool:

• As configurações de logon e firewall do servidor para o servidor secundário precisam corresponder àquelas do servidor primário.

Criar grupo de failover

Crie o grupo de failover para o pool elástico usando o portal do Azure ou o PowerShell.

Portal

Crie o grupo de failover e adicione o pool elástico a ele 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 marcá-lo como favorito e adicioná-lo como um item no menu de navegação à esquerda.

2. Selecione o pool elástico que você deseja adicionar ao grupo de failover.

3. No painel Visão Geral, escolha o nome do servidor em Nome do servidor para abrir as configurações do servidor.

   

4. Selecione Grupos de failover no painel Configurações e escolha Adicionar grupo para criar um grupo de failover.

   

5. Na página Grupo de Failover, insira ou selecione os valores solicitados e selecione Criar. Crie um novo servidor secundário ou selecione um servidor secundário existente.

6. Selecione Bancos de dados dentro do grupo e escolha o pool elástico que você deseja adicionar ao grupo de failover. Se ainda não existir um pool elástico no servidor secundário, será exibido um aviso solicitando que você crie um pool elástico no servidor secundário. Selecione o aviso e escolha OK para criar o pool elástico no servidor secundário.

   

7. Use Selecionar para aplicar as configurações de pool elástico ao grupo de failover e selecione Criar para criar o grupo de failover. A adição do pool elástico ao grupo de failover iniciará automaticamente o processo de replicação geográfica.

PowerShell

Crie o grupo de failover e adicione o pool elástico a ele usando o PowerShell.

Use o New-AzSqlDatabaseFailoverGroup para criar o grupo de failover:

# Create a failover group between the servers
Write-host "Creating failover group..." 
New-AzSqlDatabaseFailoverGroup `
  –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
Write-host "Failover group created successfully."

Use os comandos Get-AzSqlDatabaseFailoverGroup e Get-AzSqlElasticPoolDatabase para adicionar o banco de dados ao grupo de failover:

# Add elastic pool to the failover group
Write-host "Enumerating databases in elastic pool...." 
$FailoverGroup = Get-AzSqlDatabaseFailoverGroup `
                 -ResourceGroupName $resourceGroupName `
                 -ServerName $serverName `
                 -FailoverGroupName $failoverGroupName
$databases = Get-AzSqlElasticPoolDatabase `
               -ResourceGroupName $resourceGroupName `
               -ServerName $serverName `
               -ElasticPoolName $poolName
Write-host "Adding databases to failover group..." 
$failoverGroup = $failoverGroup | Add-AzSqlDatabaseToFailoverGroup `
                                  -Database $databases 
$failoverGroup

CLI do Azure

Nesta etapa, crie o grupo de failover e adiciona o banco de dados a ele usando a CLI do Azure.

Use o comando az sql failover-group create para criar um grupo de failover.

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2
databaseId=$(az sql elastic-pool list-dbs --name $pool --resource-group $resourceGroup --server $server --query [0].name -o json | tr -d '"')

Use o comando az sql failover-group update para adicionar um banco de dados ao grupo de failover.

echo "Adding $database to $failoverGroup..."
az sql failover-group update --name $failoverGroup --add-db $databaseId --resource-group $resourceGroup --server $server

Teste o failover planejado

Teste o failover do pool elástico sem perda de dados usando o portal do Azure ou o PowerShell.

Portal

Faça failover do grupo de failover para o servidor secundário e faça failback dele 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 marcá-lo como favorito e adicioná-lo como um item no menu de navegação à esquerda.

2. Selecione o pool elástico que você deseja fazer failover.

3. No painel Visão Geral, escolha o nome do servidor em Nome do servidor para abrir as configurações do servidor.

   

4. Selecione Grupos de failover em Configurações e escolha o grupo de failover criado anteriormente.

   

5. Examine qual servidor é primário e qual é secundário.

6. Selecione Failover no painel de tarefas para fazer failover do grupo de failover que contém o pool elástico.

7. Selecione Sim no aviso que notifica você de que as sessões do TDS serão desconectadas.

   

8. Examine qual servidor é primário e qual é secundário. Se o failover tiver sido bem-sucedido, os dois servidores deverão ter trocado as funções.

9. Selecione Failover novamente para fazer failback do grupo de failover para as configurações originais.

PowerShell

Teste o failover do seu grupo de failover usando o PowerShell usando os seguintes comandos do PowerShell:

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 server 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 "Failover group failed over to" $drServerName 

# Check role of secondary replica
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 "Failover group failed over to" $serverName

CLI do Azure

Teste o failover usando a CLI do Azure.

Verificar as funções de cada servidor

Use o comando az sql failover-group show para confirmar as funções de cada servidor no grupo de failover.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Fazer failover no servidor secundário

Use o comando az sql failover-group set-primary para fazer failover para o servidor secundário. Use o comando az sql failover-group show para verificar um failover bem-sucedido.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

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

Use o comando az sql failover-group set-primary para fazer failback no servidor primário.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Se for necessário excluir o banco de dados secundário, remova-o do grupo de failover antes de excluí-lo. A exclusão de um banco de dados secundário antes da remoção dele do grupo de failover pode causar um comportamento imprevisível.

Usar o Link Privado

O uso de um link privado permite associar um servidor lógico a um endereço IP privado específico dentro da rede virtual e da sub-rede.

Para usar um link privado com o grupo de failover, faça o seguinte:

1. Verifique se os servidores primários e secundários estão em uma região emparelhada.
2. Crie a rede virtual e a sub-rede em cada região para hospedar pontos de extremidade privados para servidores primários e secundários, de forma que eles tenham espaços de endereço IP não sobrepostos. Por exemplo, o intervalo de endereços de rede virtual primária de 10.0.0.0/16 e o intervalo de endereços de rede virtual secundário de 10.0.0.1/16 se sobrepõem. Para saber mais sobre intervalos de endereços de rede virtual, confira o blog Projetar redes virtuais do Azure.
3. Crie um ponto de extremidade privado e uma Zona DNS Privado do Azure para o servidor primário.
4. Crie um ponto de extremidade privado para o servidor secundário também, mas, desta vez, escolha reutilizar a mesma zona DNS Privado que foi criada para o servidor primário.
5. Depois que o link privado for estabelecido, você poderá criar o grupo de failover seguindo as etapas descritas anteriormente neste artigo.

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 mantém seu aplicativo conectado ao ouvinte do grupo de failover, em vez do banco de dados primário ou do pool elástico. 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:

Escalar bancos de dados a um grupo de failover

É possível escalar ou reduzir verticalmente o banco de dados primário para um tamanho de computação diferente (na mesma camada de serviço) sem desconectar nenhum banco de dados secundário. Ao escalar verticalmente, recomenda-se fazê-lo primeiro no secundário geográfico e, em seguida, no primário. Ao reduzir verticalmente, faça o oposto: primeiro reduza o primário e, em seguida, o secundário. Essa recomendação é aplicada quando o banco de dados é escalado para uma camada de serviço diferente.

Essa 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. Você também pode evitar o problema tornando o primário somente leitura, em detrimento de afetar todas as cargas de trabalho de leitura/gravação em relação ao primário.

Observação

Se você criou um secundário geográfico como parte da configuração do grupo de failover, não é recomendado reduzi-lo verticalmente. Isso garante que sua camada de dados tenha capacidade suficiente para processar sua carga de trabalho normal após o failover geográfico. Talvez você não consiga dimensionar uma área geográfica secundária após um failover não planejado quando a antiga área geográfica primária estiver indisponível devido à interrupção. Essa é uma limitação conhecida.

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

Para ilustrar a sequência de alteração, vamos pressupor que o servidor A é o servidor primário, o servidor B é o servidor secundário existente e o servidor C é o novo secundário na terceira região. Para fazer a transição, siga estas etapas:

1. Crie secundários adicionais de cada banco de dados no servidor A para o servidor C usando a replicação geográfica ativa. Cada banco de dados no servidor A terá dois secundários, um no servidor B e outro no servidor C. Isso garante que os bancos de dados primários permaneçam protegidos durante a transição.
2. Exclua o grupo de failover. Neste ponto, as tentativas de iniciar sessão usando pontos de extremidade do grupo de failover vão começar a falhar.
3. Crie novamente o grupo de failover com o mesmo nome entre os servidores A e C.
4. Adicione todos os bancos de dados primários do servidor A ao novo grupo de failover. Tentativas de iniciar sessão deixarão de falhar neste ponto.
5. Exclua o servidor B. Todos os bancos de dados no B serão excluídos automaticamente.

Alterar a região primária

Para ilustrar a sequência de alteração, vamos pressupor que o servidor A é o servidor primário, o servidor B é o servidor secundário existente e o servidor C é o novo primário na terceira região. Para fazer a transição, siga estas etapas:

1. Execute um failover geográfico planejado a fim de alternar o servidor primário para B. O servidor A se tornará o novo servidor secundário. O failover pode resultar em vários minutos de tempo de inatividade. O tempo real dependerá do tamanho do grupo de failover.
2. Crie secundários adicionais de cada banco de dados no servidor B para o servidor C usando a replicação geográfica ativa. Cada banco de dados no servidor B terá dois secundários, um no servidor A e outro no servidor C. Isso garante que os bancos de dados primários permaneçam protegidos durante a transição.
3. Exclua o grupo de failover. Neste ponto, as tentativas de iniciar sessão usando pontos de extremidade do grupo de failover vão começar a falhar.
4. Crie novamente o grupo de failover com o mesmo nome entre os servidores B e C.
5. Adicione todos os bancos de dados primários do B ao novo grupo de failover. Tentativas de logon deixarão de falhar neste ponto.
6. Execute um failover geográfico planejado do grupo de failover para alternar de B para C. Agora, o servidor C se tornará o primário e B será o secundário. Todos os bancos de dados secundários no servidor A serão vinculados automaticamente aos primários em C. Como na etapa 1, o failover pode resultar em vários minutos de inatividade.
7. Exclua o servidor A. Todos os bancos de dados em A serão excluídos automaticamente.

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, 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 e os aliases do DNS 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.

Grupos de failover e a segurança de rede

Em alguns aplicativos, as regras de segurança exigem que o acesso da rede à camada de dados seja restrito a componentes específicos, como uma VM, um serviço Web etc. Esse requisito apresenta alguns desafios para o design de continuidade dos negócios e o uso de grupos de failover. Considere as opções a seguir ao implementar tal acesso restrito.

Usar grupos de failover e pontos de extremidade de serviço de rede virtual

Se você está usando Pontos de extremidade e regras de serviço de Rede Virtual para restringir o acesso ao seu banco de dados, lembre-se de que cada ponto de extremidade de serviço de Rede Virtual se aplica a apenas uma região do Azure. O ponto de extremidade não permite que outras regiões aceitem a comunicação da sub-rede. Portanto, apenas os aplicativos implantados na mesma região do cliente podem se conectar ao banco de dados primário. Como um failover geográfico resulta no redirecionamento de sessões de cliente do Banco de Dados SQL para um servidor em uma região diferente (secundária), essas sessões poderão falhar se forem originadas em um cliente fora dessa região. Por esse motivo, a política de failover gerenciada pela Microsoft não poderá ser habilitada se os servidores participantes estiverem incluídos nas regras da Rede Virtual. Para dar suporte à política de failover manual, siga estas etapas:

1. Provisione as cópias redundantes dos componentes frontend do seu aplicativo (serviço Web, máquinas virtuais etc.) na região secundária.
2. Configurar as regras da rede virtual individualmente para os servidores primário e secundário.
3. Habilite o failover frontend usando uma Configuração do gerenciador de tráfego.
4. Inicie um failover geográfico manual quando a interrupção for detectada. Essa opção é otimizada para os aplicativos que precisam de latência consistente entre o frontend e a camada de dados e oferece suporte à recuperação quando o frontend, a camada de dados ou ambos são afetados pela interrupção.

Observação

Se você estiver usando o ouvinte somente leitura para balanceamento de uma carga de trabalho somente leitura, essa carga de trabalho deverá ser executada em uma VM ou outro recurso na região secundária para que possa se conectar ao banco de dados secundário.

Usar grupos de failover e regras de firewall

Se o seu plano de continuidade dos negócios exigir failover usando grupos de failover, você poderá restringir o acesso ao seu banco de dados no Banco de Dados SQL usando as regras de firewall de IP público. Essa configuração garantirá que um failover geográfico não bloqueie conexões dos componentes de frontend e pressupõe que o aplicativo pode tolerar a latência mais longa entre o frontend e a camada de dados.

Para dar suporte a um failover do grupo de failover, siga estas etapas:

1. Criar um IP público.
2. Crie um balanceador de carga público e atribua o IP público a ele.
3. Crie uma rede virtual e as máquinas virtuais para os componentes de front-end.
4. Crie um grupo de segurança de rede e configure conexões de entrada.
5. Verifique se as conexões de saída estão abertas para o Banco de Dados SQL do Azure em uma região usando uma Sql.<Region>marca de serviço.
6. Crie uma regra de firewall de Banco de Dados SQL para permitir o tráfego de entrada do endereço IP público criado na etapa 1.

Para obter mais informações de como configurar o acesso de saída e qual IP usar nas regras de firewall, confira Conexões de saída do balanceador de carga.

Importante

Para garantir a continuidade dos negócios durante interrupções regionais, garanta redundância geográfica para bancos de dados e componentes de frontend.

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 de Colaborador do SQL Server tem todas as permissões necessárias para gerenciar grupos de failover.

A tabela a seguir lista escopos de permissão específicos para o Banco de Dados SQL do Azure:

Ação	Permissão	Escopo
Criar grupo de failover	Acesso de gravação do RBAC do Azure	Servidor primário Servidor secundário Todos os bancos de dados no grupo de failover
Atualizar grupo de failover	Acesso de gravação do RBAC do Azure	Grupo de failover Todos os bancos de dados no servidor primário atual
Fazer failover de grupo de failover	Acesso de gravação do RBAC do Azure	Grupo de failover no novo servidor

Limitações

Esteja ciente das seguintes limitações:

• Os grupos de failover não podem ser criados entre dois servidores na mesma região do Azure.
• Os grupos de failover dão suporte à duplicação geográfica de todos os bancos de dados no grupo para apenas um servidor lógico secundário em uma região diferente.
• Os grupos de failover não podem ser renomeados. Será necessário excluir o grupo e recriá-lo com outro nome.
• Não há suporte para renomeação de banco de dados em banco de dados em um grupo de failover. Você precisará excluir temporariamente o grupo de failover para poder renomear um banco de dados ou remover o banco de dados do grupo de failover.
• A remoção de um grupo de failover para um banco de dados único ou em pool não interrompe a replicação e não exclui o banco de dados replicado. Será necessário interromper manualmente a duplicação geográfica e excluir o banco de dados no servidor secundário, caso você queira adicionar um banco de dados individual ou em pool novamente a um grupo de failover após sua remoção. Deixar de fazer isso poderá resultar em um erro semelhante ao The operation cannot be performed due to multiple errors na tentativa de adicionar o banco de dados ao grupo de failover.
• O nome do grupo de failover está sujeito a restrições de nomenclatura.

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-AzSqlDatabaseFailoverGroup	Esse comando cria um grupo de failover e registra-o nos servidores primário e secundário
Remove-AzSqlDatabaseFailoverGroup	Remove o grupo de failover do servidor
Get-AzSqlDatabaseFailoverGroup	Recupera a configuração de um grupo de failover
Set-AzSqlDatabaseFailoverGroup	Modifica a configuração de um grupo de failover
Switch-AzSqlDatabaseFailoverGroup	Dispara o failover de um grupo de failover para o servidor secundário
Add-AzSqlDatabaseToFailoverGroup	Adiciona um ou mais bancos de dados a um grupo de failover

Observação

É possível implantar seu grupo de failover em assinaturas usando o parâmetro -PartnerSubscriptionId no Azure Powershell começando com Az.SQL 3.11.0. Para saber mais, revise o exemplo a seguir.

CLI do Azure

Comando	Descrição
az sql failover-group create	Esse comando cria um grupo de failover e registra-o nos servidores primário e secundário
az sql failover-group delete	Remove o grupo de failover do servidor
az sql failover-group show	Recupera a configuração de um grupo de failover
az sql 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 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	Criar ou atualizar grupo de failover
Excluir grupo de failover	Remove o grupo de failover do servidor
Failover (planejado)	Dispara o failover do servidor primário atual para o servidor secundário com a sincronização de dados completa.
O Failover forçado permite a perda de dados	Dispara o failover do servidor primário atual para o servidor secundário 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 pelo servidor	Lista os grupos de failover em um servidor.
Atualizar grupo de failover	Atualiza a configuração de um grupo de failover.

Próximas etapas

Para obter uma visão geral das opções de alta disponibilidade do Banco de Dados SQL do Azure, confira a duplicação geográfica e os grupos de failover.