Partilhar via

Replicação geográfica ativa

Aplica-se a:Banco de Dados SQL do Azure

Este artigo fornece uma visão geral do recurso de replicação geográfica ativa para o Banco de Dados SQL do Azure, que permite replicar continuamente dados de um banco de dados primário para um banco de dados secundário legível. O banco de dados secundário legível pode estar na mesma região do Azure que o primário ou, mais comumente, em uma região diferente. Esse tipo de banco de dados secundário legível também é conhecido como geo-secundário ou geo-réplica.

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 .

Você também pode migrar um banco de dados SQL com replicação geográfica ativa.

Visão geral

A replicação geográfica ativa foi projetada como uma solução de continuidade de negócios. A replicação geográfica ativa permite executar a recuperação rápida de desastres de bancos de dados individuais se houver um desastre regional ou uma interrupção em grande escala. Depois que a replicação geográfica estiver configurada, você poderá iniciar um failover geográfico para um geosecundário em uma região diferente do Azure. O failover geográfico é iniciado programaticamente pela aplicação ou manualmente pelo utilizador.

O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando replicação geográfica ativa.

Diagrama de geo-replicação ativa.

Se, por qualquer motivo, o banco de dados primário falhar, você poderá iniciar um failover geográfico para qualquer um dos bancos de dados secundários. Quando um secundário é promovido à função principal, todos os outros secundários são automaticamente vinculados ao novo primário.

Você pode gerenciar a replicação geográfica e iniciar um failover geográfico usando qualquer um dos seguintes métodos:

A replicação geográfica ativa usa a tecnologia de grupo de disponibilidade Always On para replicar de forma assíncrona o log de transações gerado na réplica primária para todas as réplicas geográficas. Embora, em qualquer momento, uma base de dados secundária possa estar ligeiramente atrás da base de dados primária, é garantido que os dados numa base de dados secundária são consistentes de forma transacional. Em outras palavras, as alterações feitas por transações não confirmadas não são visíveis.

Observação

A replicação geográfica ativa replica as alterações transmitindo o log de transações do banco de dados da réplica primária para as réplicas secundárias. Ele não está relacionado à replicação transacional, que replica as alterações executando comandos DML (INSERT, UPDATE, DELETE) nos assinantes.

A replicação geográfica fornece redundância regional. A redundância regional permite que os aplicativos se recuperem rapidamente de uma perda permanente de toda uma região do Azure ou partes de uma região, causada por desastres naturais, erros humanos catastróficos ou atos mal-intencionados. O RPO de replicação geográfica pode ser encontrado em Visão geral da continuidade de negócios com o Banco de Dados SQL do Azure.

A figura a seguir mostra um exemplo de replicação geográfica ativa configurada com uma primária na região Oeste dos EUA 2 e uma geosecundária na região Leste dos EUA.

Captura de ecrã do portal do Azure a mostrar uma relação de replicação geográfica do Banco de Dados SQL.

Além da recuperação de desastres, a replicação geográfica ativa pode ser usada nos seguintes cenários:

  • Migração de banco de dados: você pode usar a replicação geográfica ativa para migrar um banco de dados de um servidor para outro com o mínimo de tempo de inatividade.
  • Atualizações de aplicações: Pode criar um secundário extra como uma cópia de recuperação durante as atualizações de aplicações.

Para alcançar a continuidade total dos negócios, adicionar redundância regional de banco de dados é apenas uma parte da solução. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica requer a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. Exemplos desses componentes incluem o software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (Recovery Time Objetive, objetivo de tempo de recuperação) do seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e capacidades que eles fornecem. Em seguida, deves tomar as medidas adequadas para garantir que o teu serviço funcione durante o failover dos serviços dos quais depende. Para obter mais informações sobre como projetar soluções para recuperação de desastres, consulte Projetando serviços disponíveis globalmente usando o Banco de Dados SQL do Azure.

Terminologia e capacidades

  • Replicação assíncrona automática

    Você só pode criar um geosecundário para um banco de dados existente. O geo-secundário pode ser criado em qualquer servidor lógico, diferente do servidor com o banco de dados primário. Uma vez criada, a réplica geosecundária é preenchida com os dados do banco de dados primário. Este processo é conhecido como semeadura. Depois de um geosecundário ser criado e propagado, as atualizações do banco de dados primário são replicadas de forma automática e assíncrona para a réplica geosecundária. A replicação assíncrona significa que as transações são confirmadas no banco de dados primário antes de serem replicadas.

  • Réplicas geosecundárias legíveis

    Um aplicativo pode aceder a uma réplica geo-secundária para executar consultas de leitura exclusiva usando as mesmas ou diferentes entidades de segurança utilizadas para aceder ao banco de dados primário. Para obter mais informações, consulte Usar réplicas de leitura para redistribuir cargas de trabalho de consultas de leitura.

    Importante

    Você pode usar a replicação geográfica para criar réplicas secundárias na mesma região da principal. Você pode usar esses secundários para satisfazer cenários de expansão de leitura na mesma região. No entanto, uma réplica secundária na mesma região não fornece resiliência adicional a falhas catastróficas ou interrupções em grande escala e, portanto, não é um destino de failover adequado para fins de recuperação de desastres. Também não garante o isolamento da zona de disponibilidade. Use a configuração redundante da zona nas camadas de serviço Business Critical ou Premium, ou na camada de serviço General Purpose, para obter o isolamento da zona de disponibilidade.

  • Failover (sem perda de dados)

    O failover alterna as funções dos bancos de dados primários e geosecundários após concluir a sincronização completa de dados para que não haja perda de dados. A duração do failover depende do tamanho do log de transações no primário que precisa ser sincronizado com o geosecundário. O mecanismo de recuperação de falhas, conhecido como failover, foi projetado para os seguintes cenários:

    • Execute exercícios de DR na produção quando a perda de dados não for aceitável
    • Realocar o banco de dados para uma região diferente
    • Retorne o banco de dados para a região primária após a interrupção ter sido atenuada (conhecida como failback).

  • Failover forçado (perda potencial de dados)

    O failover forçado alterna imediatamente o geosecundário para a função principal sem esperar pela sincronização com a principal. Todas as transações confirmadas no primário, mas ainda não replicadas para o secundário, são perdidas. Essa operação foi projetada como um método de recuperação durante interrupções quando o primário não está acessível, mas a disponibilidade do banco de dados deve ser restaurada rapidamente. Quando o primário original está online novamente, é automaticamente reconectado, resemeado usando dados atuais do primário, e torna-se o novo geo-secundário.

    Importante

    Após um failover ou um failover forçado, o endpoint de conexão para o novo primário muda porque o novo primário agora está localizado num servidor lógico diferente.

  • Várias segundárias geográficas legíveis

    Até quatro geossecundários podem ser criados para uma primária. Se houver apenas um secundário e ele falhar, o aplicativo será exposto a um risco maior até que um novo secundário seja criado. Se existirem vários secundários, o aplicativo permanecerá protegido mesmo se um dos secundários falhar. Secundários adicionais também podem ser usados para expandir cargas de trabalho somente leitura.

    Sugestão

    Se você estiver usando a replicação geográfica ativa para criar um aplicativo distribuído globalmente e precisar fornecer acesso somente leitura a dados em mais de quatro regiões, poderá criar um secundário de um secundário (um processo conhecido como encadeamento) para criar réplicas geográficas adicionais. O atraso de replicação em réplicas geográficas encadeadas pode ser maior do que em réplicas geográficas conectadas diretamente à primária. A configuração de topologias de replicação geográfica encadeadas só tem suporte programático e não no portal do Azure.

  • Replicação geográfica de bancos de dados em um pool elástico

    Cada geosecundário pode ser um único banco de dados ou um banco de dados em um pool elástico. A escolha do pool elástico para cada banco de dados geosecundário é separada e não depende da configuração de nenhuma outra réplica na topologia (primária ou secundária). Cada pool elástico está contido em um único servidor lógico. Como os nomes de banco de dados em um servidor lógico devem ser exclusivos, vários geosecundários do mesmo primário nunca podem compartilhar um pool elástico.

  • Geo-failover e failback controlados pelo usuário

    Um geosecundário que tenha terminado a propagação inicial pode ser explicitamente alternado para a função principal (failover) a qualquer momento pelo aplicativo ou pelo usuário. Durante uma interrupção em que o primário está inacessível, apenas o failover forçado pode ser usado, o que promove imediatamente um geo-secundário para ser o novo primário. Quando a interrupção é atenuada, o sistema torna automaticamente o primário recuperado um geosecundário e o atualiza up-tocom o novo primário. Devido à natureza assíncrona da replicação geográfica, as transações recentes podem ser perdidas durante transferências forçadas se o primário falhar antes que essas transações sejam replicadas para um secundário geográfico. Quando um primário com vários geosecundários faz failover, o sistema reconfigura automaticamente as relações de replicação e vincula os geosecundários restantes ao primário recém-promovido, sem exigir qualquer intervenção do usuário. Depois de a interrupção que causou o failover geográfico ser atenuada, pode ser desejável retornar o servidor primário à sua região original. Para isso, realize uma alternância manual.

  • Réplica em espera

    Se sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver nenhuma carga de trabalho de leitura ou gravação, você poderá designá-la como em espera para economizar nos custos de licenciamento.

Prepare-se para mudança geográfica automática

Para garantir que seu aplicativo possa acessar imediatamente o novo primário após o failover geográfico, valide se a autenticação e o acesso à rede para o servidor secundário estão configurados corretamente. Para obter detalhes, consulte Configurar e gerir a segurança do Banco de Dados SQL do Azure para restauração geográfica ou recuperação automática. Valide também se a política de retenção de backup no banco de dados secundário corresponde à do banco de dados principal. Essa configuração não faz parte do banco de dados e não é replicada do principal. Por padrão, o geosecundário é configurado com um período de retenção PITR padrão de sete dias. Para obter mais informações, consulte Backups automatizados no Banco de Dados SQL do Azure.

Importante

Se o banco de dados for membro de um grupo de failover, não será possível iniciar o failover usando o comando de failover de replicação geográfica. Use o comando failover para o grupo. Se você precisar fazer failover de um banco de dados individual, deverá removê-lo do grupo de failover primeiro. Consulte Grupos de tolerância a falhas para obter detalhes.

Configurar geo-secundário

Tanto o primário quanto o geosecundário devem ter a mesma camada de serviço. Também é altamente recomendável que o geo-secundário seja configurado com a mesma redundância de armazenamento de cópias de segurança, camada de computação (provisionada ou sem servidor) e tamanho de computação (DTUs ou vCores) que o primário. Se o primário estiver enfrentando uma carga de trabalho de gravação pesada, um geosecundário com um tamanho de computação menor pode não ser capaz de acompanhar. Isso causa atraso de replicação no geo-secundário e pode, eventualmente, resultar na indisponibilidade do geo-secundário. Para mitigar esses riscos, a replicação geográfica ativa reduz (limita) a taxa de log de transações do primário, se necessário, para permitir que seus secundários se atualizem.

Outra consequência de uma configuração geosecundária desequilibrada é que, após o failover, o desempenho do aplicativo pode ser prejudicado devido à capacidade de computação insuficiente do novo primário. Nesse caso, é necessário aumentar a escala do banco de dados para ter recursos suficientes, o que pode levar um tempo significativo e requer um failover de alta disponibilidade no final do processo de expansão, o que pode interromper as cargas de trabalho do aplicativo.

Se você decidir criar o geosecundário com uma configuração diferente, deverá monitorar a taxa de E/S de log no primário ao longo do tempo. Isto permite-lhe estimar o tamanho de computação mínimo da georreplicação secundária necessário para manter a carga de replicação. Por exemplo, se seu banco de dados primário for P6 (1000 DTU) e sua E/S de log for mantida em 50%, o geosecundário precisará ser pelo menos P4 (500 DTU). Para recuperar dados históricos de E/S de log, utilize a vista sys.resource_stats. Para recuperar dados de E/S de log recentes com maior granularidade, que refletem melhor os picos de curto prazo, use a visualização sys.dm_db_resource_stats.

Sugestão

A limitação de E/S do log de transações pode ocorrer:

  • Se o geo-secundário estiver em um tamanho de computação menor do que o primário. Verifique o tipo de espera HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO nas visualizações de banco de dados sys.dm_exec_requests e sys.dm_os_wait_stats.
  • Razões não relacionadas ao tamanho do cálculo. Para obter detalhes, incluindo tipos de espera para diferentes tipos de limitação de E/S de log, consulte Governança da taxa de log de transações.

Por padrão, a redundância de armazenamento de backup do geosecundário é a mesma do banco de dados primário. Você pode optar por configurar um geo-secundário com uma redundância de armazenamento de backup diferente. Os backups são sempre feitos no banco de dados primário. Se o secundário estiver configurado com uma redundância de armazenamento de backup diferente, após um failover geográfico, quando o geo-secundário for promovido a primário, os novos backups serão armazenados e faturados de acordo com o tipo de armazenamento (RA-GRS, ZRS, LRS) selecionado no novo primário (que era o secundário anterior).

Economize nos custos com a réplica em standby

Se sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver cargas de trabalho de leitura ou gravação, você poderá economizar nos custos de licenciamento designando o banco de dados para espera ao configurar uma nova relação de replicação geográfica ativa.

Reveja a réplica em espera livre de licenças para saber mais.

Replicação geográfica entre assinaturas

  • Você pode usar o portal do Azure para configurar a replicação geográfica ativa entre assinaturas, desde que ambas as assinaturas estejam no mesmo locatário do Microsoft Entra.

  • Não há suporte para a criação de um geo-secundário entre subscrições num servidor lógico, seja no mesmo locatário ou num locatário diferente do Microsoft Entra, quando a autenticação apenas do Microsoft Entra está habilitada no servidor lógico primário ou secundário e a criação é tentada usando um utilizador do ID do Microsoft Entra.

Para obter métodos e instruções passo a passo, consulte Tutorial: Configurar replicação geográfica ativa e failover (Banco de Dados SQL do Azure).

Terminais privados

Não há suporte para a adição de um geosecundário usando T-SQL ao se conectar ao servidor primário por meio de um ponto de extremidade privado.

  • Se um ponto de extremidade privado estiver configurado, mas o acesso à rede pública for permitido, a adição de um geosecundário será suportada quando conectado ao servidor primário a partir de um endereço IP público.
  • Após a adição de um geo-secundário, o acesso à rede pública pode ser negado.

Mantenha as credenciais e as regras de firewall sincronizadas

Ao usar o acesso à rede pública para se conectar ao banco de dados, recomendamos o uso de regras de firewall IP no nível de banco de dados para bancos de dados replicados geograficamente. Essas regras são replicadas com o banco de dados, o que garante que todos os geosecundários tenham as mesmas regras de firewall IP do primário. Essa abordagem elimina a necessidade de os clientes configurarem e manterem manualmente regras de firewall em servidores que hospedam os bancos de dados primários e secundários. Da mesma forma, o uso de usuários de banco de dados contidos para acesso a dados garante que os bancos de dados primários e secundários sempre tenham as mesmas credenciais de autenticação. Dessa forma, após um failover geográfico, não há interrupções devido a incompatibilidades de credenciais de autenticação. Se você estiver usando logins e usuários (em vez de usuários contidos), deverá tomar medidas adicionais para garantir que os mesmos logons existam para seu banco de dados secundário. Para obter detalhes de configuração, consulte Configurar e gerir a segurança do Banco de Dados SQL do Azure para geo-restauro ou falha de segurança.

Dimensionar banco de dados primário

Você pode aumentar ou reduzir a escala do banco de dados primário para um tamanho de computação diferente (dentro da mesma camada de serviço) sem desconectar nenhum geo-secundário. Ao aumentar a escala, recomendamos que se escale primeiro o geosecundário e, em seguida, o primário. Ao reduzir a escala, inverta a ordem: reduza o primário primeiro e, em seguida, diminua o secundário.

Para obter informações sobre grupos de failover, consulte dimensionar uma réplica em um grupo de failover.

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. Chamar sp_wait_for_database_copy_sync bloqueia o encadeamento de chamada até que a última transação confirmada tenha sido transmitida e consolidada no log de transações do banco de dados secundário. Também aguarda 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.

Observação

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

Monitorizar o atraso da georreplicação

Para monitorizar o atraso em relação ao RPO, utilize a coluna replication_lag_sec de sys.dm_geo_replication_link_status na base de dados primária. Mostra o atraso em segundos entre as transações consolidadas na primária e protegidas no registo de transações na secundária. Por exemplo, se o atraso for de um segundo, isso significa que, se o primário for afetado por uma interrupção neste momento e um failover geográfico for iniciado, as transações confirmadas no último segundo serão perdidas.

Para medir o atraso em relação às alterações no banco de dados primário que foram consolidadas no geosecundário, compare o tempo last_commit no geosecundário com o mesmo valor no primário.

Sugestão

Se replication_lag_sec no primário for NULL, isso significa que o primário atualmente não sabe quão atrasado um geo-secundário está. Isso normalmente acontece após o processo ser reiniciado e deve ser uma condição transitória. Considere enviar um alerta se replication_lag_sec retornar NULL durante um período prolongado. Isso pode indicar que o geo-secundário não pode se comunicar com o primário devido a uma falha de conectividade.

Há também condições que podem fazer com que a diferença entre o tempo de last_commit no geo-secundário e no primário aumente significativamente. Por exemplo, se uma confirmação for feita no primário após um longo período sem alterações, a diferença saltará para um valor grande antes de retornar rapidamente a zero. Considere enviar um alerta se a diferença entre esses dois valores permanecer grande por muito tempo.

Gerencie programaticamente a replicação geográfica ativa

A replicação geográfica ativa também pode ser gerenciada programaticamente usando T-SQL, Azure PowerShell e API REST. As tabelas a seguir descrevem o conjunto de comandos disponíveis. A replicação geográfica ativa inclui 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 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).

Importante

Esses comandos T-SQL só se aplicam à replicação geográfica ativa e não se aplicam a grupos de failover.

Comando Descrição
ALTERAR BASE DE DADOS Use o argumento ADD SECONDARY ON SERVER para criar um banco de dados secundário para um banco de dados existente e iniciar a replicação de dados
ALTERAR BASE DE DADOS Use FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS para mudar um banco de dados secundário para ser primário para iniciar o failover
ALTERAR BASE DE DADOS Use REMOVE SECONDARY ON SERVER para encerrar uma replicação de dados entre um Banco de dados SQL e o banco de dados secundário especificado.
sys.geo_replication_links Retorna informações sobre todos os links de replicação existentes para cada banco de dados em um servidor.
sys.dm_geo_replication_link_status Obtém o último tempo de replicação, o último atraso de replicação e outras informações sobre o link de replicação para um determinado banco de dados.
sys.dm_operation_status Mostra o status de todas as operações de banco de dados, incluindo alterações em links de replicação.
sys.sp_wait_for_database_copy_sync Faz com que a aplicação aguarde até que todas as transações confirmadas sejam gravadas no registo de transações de um geo-secundário.

Conteúdo relacionado

Configure a replicação geográfica ativa:

Outros conteúdos de continuidade de negócios: