Compartilhar via

Replicação geográfica ativa

Applies to:Azure SQL Database

Este artigo fornece uma visão geral do recurso de replicação geográfica ativo para Azure SQL Database, 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 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 réplica geográfica.

A replicação geográfica ativa é configurada por banco de dados. Para realizar um "failover" em um grupo de bancos de dados, ou se o seu aplicativo exigir um ponto de extremidade de conexão estável, considere usar 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 dos negócios. A replicação geográfica ativa permite a rápida recuperação 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 for configurada, você poderá iniciar um failover geográfico para um secundário geográfico em uma região de Azure diferente. O failover geográfico é iniciado programaticamente pelo aplicativo ou manualmente pelo usuário.

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

Diagrama de replicação geográfica ativa.

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

É possível 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 um banco de dados secundário possa estar em algum momento um pouco desatualizado com relação ao primário, os dados nele têm a garantia de serem transacionalmente consistentes. 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 secundárias. Ele não está relacionado à replicação transacional, que replica as alterações executando comandos DML (INSERT, UPDATE, DELETE) em 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 uma região Azure inteira 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 Continuidade de negócios no Azure SQL Database.

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

Screenshot do portal Azure exibindo 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: é possível usar a replicação geográfica ativa para migrar um banco de dados de um servidor para outro com tempo de inatividade mínimo.
  • Atualizações de Aplicativos: você pode criar um secundário extra como uma cópia de recuperação durante as atualizações de aplicativos.

Adicionar a redundância regional do banco de dados é apenas uma parte da solução para obter uma continuidade de negócios completa. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica exige a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. O software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS são exemplos desses componentes. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (objetivo de tempo de recuperação) de seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e os recursos que eles fornecem. Em seguida, você deve tomar as medidas necessárias para garantir que seu serviço funcione durante o failover dos serviços dos quais ele depende. Para obter mais informações sobre como criar soluções para recuperação de desastre, consulte Designing de serviços disponíveis globalmente usando Azure SQL Database.

Terminologia e recursos

  • Replicação assíncrona automática: você só pode criar um secundário geográfico para um banco de dados existente. O secundário geográfico pode ser criado em qualquer servidor lógico diferente daquele com o banco de dados primário. Depois de criada, a réplica geográfica secundária é preenchida com os dados do banco de dados primário. Este processo é conhecido como seeding. Depois de criar e propagar a réplica geográfica secundária, as atualizações no banco de dados primário serão replicadas nela automaticamente e de maneira assíncrona. 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 geo-secundárias legíveis: um aplicativo pode acessar uma réplica geo-secundária para executar consultas somente leitura usando os mesmos ou diferentes princípios de segurança usados para acessar o banco de dados primário. Para mais informações, veja Como usar réplicas de leitura para distribuir cargas de trabalho de consulta somente leitura.

Importante

É possível usar a replicação geográfica para criar réplicas secundárias na mesma região do banco de dados primário. Você pode usar esses secundários para atender aos 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 de grande escala e, portanto, não é um destino de failover adequado para fins de recuperação de desastres. Ele também não garantirá o isolamento da zona de disponibilidade. Use a configuração de redundância de zona da camada de serviço Comercialmente Crítico ou Premium ou a configuração de redundância de zona da camada de serviço Uso Geral para obter o isolamento de zona de disponibilidade.

  • Failover (sem perda de dados): quando um Failover (sem perda de dados) é iniciado, uma etapa de sincronização de dados completa é concluída antes de alternar as funções dos bancos de dados primários e geográficos secundários. Isso garante que não haja perda de dados. A duração do failover depende do tamanho do log de transações na instância primária, que precisa ser sincronizado com a instância geográfica secundária. O failover foi projetado para os seguintes cenários:

    • Realizar simulações de recuperação de desastre em produção quando a perda de dados não é aceitável
    • Relocar o banco de dados para uma região diferente
    • Restaurar o banco de dados para a região primária após a mitigação da interrupção (failback).

  • Failover forçado (potencial perda de dados): o failover forçado muda imediatamente o geo-secundário para a função primária sem aguardar a sincronização com o primário. Todas as transações confirmadas no primário, mas não replicadas no secundário, serão perdidas. Essa operação foi projetada como um método de recuperação durante interrupções quando o sistema primário não está acessível, mas a disponibilidade do banco de dados precisa ser restaurada rapidamente. Quando o primário original estiver online novamente, ele será reconectado automaticamente, repopulado com os dados atuais do primário e se tornará o novo secundário geográfico.

Importante

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

  • Várias secundárias geográficas legíveis: até quatro secundários geográficos podem ser criados para um primário. 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 houver vários secundários, o aplicativo permanecerá protegido mesmo em caso de falha em um dos secundários. Secundários adicionais também podem ser usados para expandir as cargas de trabalho somente leitura.

Dica

Ao usar a replicação geográfica ativa para compilar um aplicativo distribuído globalmente, se for necessário fornecer acesso somente leitura aos dados em mais de quatro regiões, você poderá criar um secundário de outro secundário (um processo conhecido como encadeamento), a fim de criar réplicas geográficas adicionais. O retardo de replicação em réplicas geográficas encadeadas pode ser maior do que em réplicas geográficas conectadas diretamente ao primário. A configuração de topologias de replicação geográfica encadeada só tem suporte programaticamente e não do portal Azure.

  • Replicação geográfica de bancos de dados em um pool elástico: cada secundário geográfico pode ser um banco de dados individual ou um banco de dados em um pool elástico. A escolha do pool elástico para cada banco de dados geográfico secundário é distinta e não depende da configuração de qualquer 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 secundários geográficos do mesmo primário nunca podem compartilhar um pool elástico.

  • Failover geográfico controlado pelo usuário e retorno após falha: Um secundário geográfico que concluiu a transferência inicial pode ser explicitamente alternado para a função primária (failover) a qualquer momento pelo aplicativo ou pelo usuário. Durante uma interrupção em que o primário está inacessível, somente o failover forçado pode ser usado, o que promove imediatamente um secundário geográfico como novo primário. Quando a interrupção é mitigada, o sistema transforma automaticamente o primário recuperado em um secundário geográfico e o atualiza em relação ao novo primário. Devido à natureza assíncrona da duplicação geográfica, as transações recentes podem ser perdidas durante failovers forçados caso o primário falhe antes dessas transações serem replicadas em um secundário geográfico. Quando um primário com vários secundários geográficos passa por failover, o sistema reconfigura automaticamente as relações de replicação e vincula os secundários geográficos restantes ao primário recém-promovido, sem a necessidade de intervenção do usuário. Depois que a interrupção que causou o failover geográfico é reduzida, recomenda-se retornar o primário para a região original. Para fazer isso, execute um failover manual.

  • Réplica em espera: se a réplica secundária for usada apenas para recuperação de desastre (DR) e não tiver cargas de trabalho de leitura ou gravação, você poderá designar a réplica como em espera para economizar nos custos de licenciamento.

Preparar-se para o failover geográfico

Para garantir que o aplicativo consiga acessar imediatamente o novo primário após o failover geográfico, confirme se o acesso de rede e a autenticação do servidor secundário estão configurados corretamente. Para obter detalhes, consulte Configurar e gerenciar a segurança do Azure SQL Database para restauração geográfica ou failover. Confirme também se a política de retenção de backup no banco de dados secundário corresponde à do primário. Essa configuração não faz parte do banco de dados e não é replicada do primário. Por padrão, o secundário geográfico será configurado com um período de retenção de PITR padrão de sete dias. Para obter mais informações, consulte Backupsautomatizados no Azure SQL Database.

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 de failover para o grupo. Se precisar fazer failover de um banco de dados individual, você deverá primeiro removê-lo do grupo de failover. Consulte visão geral dos grupos de failover e melhores práticas (Azure SQL Database) para mais detalhes.

Configurar o secundário geográfico

O primário e o geo-secundário devem ter a mesma camada de serviço. Também é altamente recomendado que o secundário geográfico seja configurado com a mesma redundância de armazenamento de backup, nível de computação (provisionado ou sem servidor) e tamanho de computação (DTUs ou vCores) que o primário. Se o primário estiver com uma carga de trabalho de gravação pesada, um geo-secundário com uma capacidade de computação menor poderá não ser capaz de acompanhar. Isso causa retardo de replicação no secundário geográfico e, eventualmente, pode causar a indisponibilidade dele. Para reduzir esses riscos, a replicação geográfica ativa diminui (restringe) a taxa do log de transações do primário, se necessário, para permitir que os secundários alcancem o primário.

Outra consequência de uma configuração geográfica secundária desbalanceada é que, após o failover, o desempenho do aplicativo pode ser afetado devido à capacidade de computação insuficiente do novo primário. Nesse caso, é necessário ampliar o banco de dados para que ele tenha recursos suficientes, o que pode exigir tempo significativo, e executar um failover de alta disponibilidade após a conclusão do processo de ampliação, o que pode interromper as cargas de trabalho do aplicativo.

Dica

Para obter diretrizes detalhadas de solução de problemas sobre o retardo na replicação geográfica, consulte Solucionar problemas de retardo na replicação geográfica.

Se você decidir criar o secundário geográfico com uma configuração diferente, deverá monitorar a taxa de E/S de log no primário ao longo do tempo. Isso permite estimar o tamanho mínimo de computação do secundário geográfico que é necessário para sustentar a carga de replicação. Por exemplo, se o banco de dados primário for P6 (1000 DTU) e seu I/O de log for mantido em 50%, o secundário geográfico precisará ser pelo menos P4 (500 DTU). Para recuperar dados históricos de E/S de log, use a exibição sys.resource_stats. Para recuperar dados de E/S de log recentes com uma granularidade maior, que melhor reflete picos de curto prazo, use a visualização sys.dm_db_resource_stats.

Dica

A restrição de E/S do log de transações pode ocorrer nos seguintes cenários:

  • Se o secundário geográfico estiver em um tamanho de computação menor que o primário. Procure pelo tipo de espera HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO nas visões de banco de dados sys.dm_exec_requests e sys.dm_os_wait_stats.
  • A limitação também pode ocorrer por motivos não relacionados ao porte do processamento, por exemplo, em cargas de trabalho pesadas para inserção em massa SELECT INTO e criação de índices. Para obter mais informações sobre tipos de espera para diferentes tipos de limitação de E/S de log, consulte a governança da taxa de log de transações.

Por padrão, a redundância de armazenamento de backup do secundário geográfico é a mesma do banco de dados primário. É possível optar por configurar o secundário geográfico 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 o failover geográfico, quando o secundário for promovido a primário, os novos backups serão armazenados e cobrados de acordo com o tipo de armazenamento selecionado no novo primário (anteriormente secundário), como RA-GRS, ZRS ou LRS.

Economize nos custos com a réplica em espera

Se sua réplica secundária for usada apenas para DR (recuperação de desastre) 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.

Examine Réplica de espera sem licença para saber mais.

Replicação geográfica entre assinaturas

  • Você pode usar o portal Azure para configurar a georeplicação ativa entre assinaturas, desde que ambas as assinaturas estejam no mesmo tenant do Microsoft Entra.

    • Para criar uma réplica geográfica secundária em uma assinatura diferente da assinatura do primário em um locatário Microsoft Entra diferente, use a autenticação SQL e T-SQL. Autenticação do Microsoft Entra para Azure SQL para replicação geográfica entre assinaturas não é suportada quando um servidor lógico está em um tenant Azure diferente
    • As operações de replicação geográfica entre assinaturas, incluindo a configuração e o failover geográfico, são também suportadas usando a API REST Databases Create or Update.

  • Não há suporte para a criação de um secundário geográfico entre assinaturas em um servidor lógico no mesmo ou em um locatário Microsoft Entra diferente quando autenticação somente Microsoft Entra com Azure SQL está habilitada no servidor lógico primário ou secundário e a criação é tentada usando um usuário de ID do Microsoft Entra.

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

Pontos de extremidade privados

Não há suporte para a adição de uma localização geográfica secundária usando T-SQL ao se conectar com o servidor primário em um ponto de extremidade privado.

Se um ponto de extremidade privado estiver configurado, mas o acesso à rede pública for permitido, haverá suporte para a adição de uma localização geográfica secundária quando conectada ao servidor primário por um endereço IP público.

Depois que uma localização geográfica secundária é adicionada, o acesso à rede pública pode ser negado.

Manter credenciais e regras de firewall em sincronização

Ao usar o acesso de rede pública para se conectar ao banco de dados, recomendamos usar regras de firewall de IP de nível de banco de dados para bancos de dados georredundantes. Essas regras são replicadas com o banco de dados, o que garante que todos os secundários geográficos tenham as mesmas regras de firewall de IP que o primário. Essa abordagem evita que os clientes tenham de configurar e manter manualmente as regras de firewall nos servidores que hospedam os bancos de dados primários e secundários. Da mesma forma, o uso de usuários de banco de dados independente para acesso a dados garante que os bancos de dados primário e secundário 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 logons e usuários (em vez de usuários independentes), precisará realizar etapas extras para garantir que os mesmos logons existam no banco de dados secundário. Para obter detalhes de configuração, consulte Configurar e gerenciar a segurança do Azure SQL Database para restauração geográfica ou failover.

Escalar banco de dados primário

É possível aumentar ou diminuir o banco de dados principal para uma capacidade de computação diferente (na mesma camada de serviço) sem desconectar nenhum banco de dados secundário geográfico. Ao escalar verticalmente, recomenda-se fazê-lo primeiro no secundário geográfico e, em seguida, no primário. Ao reduzir, inverta a ordem: primeiro reduza o primário e, em seguida, o secundário.

Para obter informações sobre conjuntos de failover, confira escalar uma réplica em um conjunto 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. 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. Ele também aguarda que as transações transmitidas sejam reproduzidas (refeitas) no secundário. O procedimento armazenado do sp_wait_for_database_copy_sync sistema tem como escopo 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 previne a perda de dados após o failover geográfico de transações específicas, mas não garante sincronização total 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.

Monitoramento do retardo da replicação geográfica

Para monitorar o atraso em relação ao RPO, use a coluna replication_lag_sec de sys.dm_geo_replication_link_status no banco de dados primário. O sistema mostra a latência em segundos entre as transações comprometidas no servidor primário e registradas no log de transações do servidor secundário. Por exemplo, se o retardo for de um segundo, isso significará 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 retardo em relação às alterações no banco de dados primário que foram confirmadas no secundário geográfico, compare o tempo last_commit no secundário geográfico com o mesmo valor no primário.

Dica

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

Existem condições que podem fazer com que a diferença entre last_commit o tempo 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 para zero. Considere o envio de um alerta se a diferença entre esses dois valores permanecer grande por um longo tempo.

Gerenciar a replicação geográfica ativa programaticamente

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 de Azure Resource Manager para gerenciamento, incluindo a API REST do Azure SQL Database e os 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 Azure controle de acesso baseado em função (Azure RBAC).

Importante

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

Comando Descrição
ALTERAR BANCO DE DADOS Usar ADD SECONDARY ON SERVER o argumento para criar um banco de dados secundário para um banco de dados existente e iniciar a replicação de dados
ALTERAR BANCO DE DADOS Use FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS para alternar um banco de dados secundário para primário e iniciar o failover
ALTERAR BANCO 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 a hora da última replicação, retardo da última 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 o aplicativo aguarde até que todas as transações confirmadas sejam persistidas no log de transações de um secundário geográfico.

Solução de problemas

Para obter mais informações sobre como solucionar problemas de retardo de réplica geográfica, consulte Solucionar problemas de retardo de replicação geográfica.

Conteúdo relacionado

Configurar a replicação geográfica ativa:

Outros conteúdos de continuidade dos negócios:

  • Last updated on