Tutorial: Configurar geo-replicação ativa e failover (Base de Dados SQL do Azure)

Aplica-se a: Base de Dados SQL do Azure

Este artigo mostra-lhe como configurar a geo-replicação ativa e iniciar um failover para o Base de Dados SQL do Azure usando o portal Azure, PowerShell ou a CLI do Azure.

A replicação geográfica ativa é configurada por banco de dados. Para fazer failover de um grupo de bancos de dados, ou se seu aplicativo exigir um ponto de extremidade de conexão estável, considere grupos de failover .

Pré-requisitos

• Para completar este tutorial, precisa de uma única Base de Dados SQL do Azure. Para aprender a criar uma base de dados única com o portal Azure, CLI do Azure ou PowerShell, consulte Quickstart: Criar uma base de dados única - Base de Dados SQL do Azure.

• Pode usar o portal do Azure para configurar a replicação geográfica ativa entre subscrições, desde que ambas as subscrições estejam no mesmo tenant do Microsoft Entra ID.

  • Para criar uma réplica geo-secundária numa subscrição diferente da subscrição principal num tenant Microsoft Entra ID diferente, use a geo-secundária entre subscrições e o tutorial T-SQL do tenant Microsoft Entra ID.
  • As operações de replicação geográfica entre assinaturas, incluindo configuração e failover geográfico, também são suportadas usando a API REST de Criação ou Atualização de Bancos de Dados.

Adicionar um banco de dados secundário

Os passos seguintes criam uma nova base de dados secundária numa parceria de geo-replicação.

Para adicionar uma base de dados secundária, deve ser o proprietário ou coproprietário da subscrição.

A base de dados secundária tem o mesmo nome da base de dados principal e, por defeito, o mesmo nível de serviço e tamanho de computação. A base de dados secundária pode ser uma base de dados única ou uma base de dados agrupada. Para mais informações, consulte a visão geral do modelo de compras baseado em DTU e o modelo de compras baseado em vCore. Depois de a secundária ser criada e semeada, os dados começam a replicar-se da base de dados primária para a nova base de dados secundária.

Se a sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver cargas de trabalho de leitura ou escrita, pode poupar nos custos de licenciamento designando a base de dados como standby quando configurar uma nova relação ativa de geo-replicação. Para mais informações, consulte réplica de espera sem licença.

az sql db replica create --resource-group ContosoHotel --server contosoeast --name guestlist --partner-server contosowest --family Gen5 --capacity 2 --secondary-type Geo

az sql db replica list-links --name guestlist --resource-group ContosoHotel --server contosowest

Connect-AzAccount
$subscriptionid = <your subscription id here>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = 'PrimaryRG'
    ServerName = 'PrimaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'SecondaryRG'
    PartnerServerName = 'SecondaryServer'
    PartnerDatabaseName = 'TestDB'
}

New-AzSqlDatabaseSecondary @parameters

$parameters = @{
    ResourceGroupName = 'PrimaryRG'
    ServerName = 'PrimaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'SecondaryRG'
}

Get-AzSqlDatabaseReplicationLink @parameters

Iniciar um failover

A base de dados secundária pode ser alterada para se tornar a principal.

az sql db replica set-primary --name guestlist --resource-group ContosoHotel --server contosowest

$parameters = @{
    ResourceGroupName = 'SecondaryRG'
    ServerName = 'SecondaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'PrimaryServer'
}

Set-AzSqlDatabaseSecondary @parameters -Failover

O comando muda imediatamente a base de dados secundária para a função principal. Este processo normalmente deve concluir-se em 30 segundos ou menos.

Ambas as bases de dados ficam indisponíveis durante um período de até 25 segundos, enquanto as funções são trocadas. Se a base de dados primária tiver múltiplas bases de dados secundárias, o comando reconfigura automaticamente as outras secundárias para se ligarem à nova base primária. Em circunstâncias normais, toda a operação deveria demorar menos de um minuto.

Remover banco de dados secundário

Esta operação interrompe permanentemente a replicação da base de dados secundária e altera a função da base de dados secundária para uma base de dados normal de leitura e escrita. Se a conectividade à base de dados secundária for interrompida, o comando é executado com êxito, mas a base de dados secundária só fica em modo de leitura e escrita depois de a conectividade ser restabelecida.

az sql db replica delete-link --name guestlist --resource-group ContosoHotel --server contosoeast --partner-server contosowest

$parameters = @{
    ResourceGroupName = 'SecondaryRG'
    ServerName = 'SecondaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'PrimaryRG'
    PartnerServerName = 'PrimaryServer'
}
Remove-AzSqlDatabaseSecondary @parameters

Replicação geográfica entre assinaturas

• Para criar uma réplica geosecundária numa subscrição diferente da subscrição da principal no mesmo tenant do Microsoft Entra, pode utilizar o portal do Azure ou seguir os passos desta secção.
• Para criar uma réplica geosecundária numa subscrição diferente da subscrição da base de dados primária num tenant do Microsoft Entra diferente, deve utilizar a autenticação SQL e o T-SQL, conforme descrito nas etapas desta secção. Autenticação do Microsoft Entra para o SQL do Azure para georreplicação entre subscrições não é suportada quando um servidor lógico está num tenant do Azure diferente

1. Adicione o endereço IP da máquina cliente que executa os comandos T-SQL neste exemplo, aos firewalls dos servidores principal e secundário. Pode confirmar esse endereço IP executando a seguinte consulta enquanto está ligado ao servidor principal a partir da mesma máquina cliente.

   SELECT client_net_address
   FROM sys.dm_exec_connections
   WHERE session_id = @@SPID;
   

   Para mais informações, consulte Base de Dados SQL do Azure e Azure Synapse regras de firewall IP.

2. Na master base de dados do servidor principal , crie um login de autenticação SQL dedicado à configuração ativa de geo-replicação. Ajuste o nome de login e a palavra-passe conforme necessário.

   CREATE LOGIN geodrsetup
       WITH PASSWORD = 'ComplexPassword01';
   

3. Na mesma base de dados, crie um utilizador para o login e adicione-o à função dbmanager:

   CREATE USER geodrsetup FOR LOGIN geodrsetup;
   
   ALTER ROLE dbmanager ADD MEMBER geodrsetup;
   

4. Toma nota do valor do SID do novo login. Obtenha o valor SID usando a seguinte consulta.

   SELECT sid
   FROM sys.sql_logins
   WHERE name = 'geodrsetup';
   

5. Liga-te à base de dados principal (não à master base de dados) e cria um utilizador para o mesmo login.

   CREATE USER geodrsetup FOR LOGIN geodrsetup;
   

6. Na mesma base de dados, adiciona o utilizador à função db_owner.

   ALTER ROLE db_owner ADD MEMBER geodrsetup;
   

7. Na master base de dados do servidor secundário , crie o mesmo login que no servidor principal, usando o mesmo nome, palavra-passe e SID. Substitua o valor hexadecimal do SID no comando de exemplo abaixo pelo obtido no Passo 4.

   CREATE LOGIN geodrsetup
       WITH PASSWORD = 'ComplexPassword01', SID = 0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. Na mesma base de dados, cria um utilizador para o login e adiciona-o à dbmanager função.

   CREATE USER geodrsetup FOR LOGIN geodrsetup;
   
   ALTER ROLE dbmanager ADD MEMBER geodrsetup;
   

9. Estabeleça ligação à base de dados master no servidor principal utilizando o novo início de sessão geodrsetup e inicie a criação da geo-secundária no servidor secundário. Ajustar o nome da base de dados e o nome do servidor secundário conforme necessário. Depois de o comando ser executado, pode monitorizar a criação da réplica geosecundária consultando a vista sys.dm_geo_replication_link_status na base de dados primária e a vista sys.dm_operation_status na base de dados master no servidor primário. O tempo necessário para criar uma geo-secundária depende do tamanho da base de dados primária.

   alter database [dbrep] add secondary on server [servername];
   

10. Depois de o geo-secundário ser criado com sucesso, os utilizadores, logins e regras de firewall criados por este procedimento podem ser removidos.

Conteúdo relacionado

• Replicação geográfica ativa
• Visão geral dos grupos de failover & práticas recomendadas (Banco de Dados SQL do Azure)
• Visão geral da continuidade do negócio com Base de Dados SQL do Azure
• Configurar uma réplica em espera sem licença para o Banco de Dados SQL do Azure