Partilhar via

Fiabilidade no Azure DocumentDB

Este artigo contém informações detalhadas sobre resiliência regional com zonas de disponibilidade e recuperação de desastres entre regiões e continuidade de negócios para o Azure DocumentDB.

Para obter uma visão geral da arquitetura da confiabilidade no Azure, consulte Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Para obter suporte à zona de disponibilidade, você deve habilitar Alta disponibilidade (HA).

A HA evita o tempo de inatividade do banco de dados mantendo réplicas em espera de cada fragmento em um cluster. Se um shard falhar, o Azure DocumentDB troca as ligações recebidas do shard falhado para a sua réplica de espera.

Quando a HA é habilitada em uma região que oferece suporte a zonas de disponibilidade, os fragmentos de réplica de HA são provisionados em uma zona de disponibilidade diferente de seus fragmentos primários. As réplicas de HA não recebem solicitações de clientes, a menos que seu fragmento principal falhe.

Se o HA estiver desabilitado, cada fragmento terá seu próprio LRS (armazenamento com redundância local) com três réplicas síncronas mantidas pelo serviço de Armazenamento do Azure. Se houver uma única falha de réplica, o serviço de Armazenamento do Azure detetará a falha e recriará os dados relevantes de forma transparente. Para a durabilidade do armazenamento LRS, consulte Resumo das opções de redundância. No entanto, se uma região falhar, corre-se o risco de um longo tempo de inatividade e possível perda de dados.

Criar um recurso com zonas de disponibilidade ativadas

Para habilitar zonas de disponibilidade, você deve habilitar Alta disponibilidade (HA) ao criar um cluster ou na seção Escala de um cluster existente no portal do Azure.

Recuperação de desastres entre regiões e continuidade de negócios

A recuperação de desastres (DR) refere-se a práticas que as organizações usam para se recuperar de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Para DR, a Microsoft usa o modelo de responsabilidade compartilhada . Neste modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam dados automaticamente nem possuem mecanismos de fallback para mudar de uma região com falha para outra região ativada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas da plataforma Azure como serviço (PaaS) fornece recursos e orientações para dar suporte à DR. Você pode usar recursos específicos do serviço para apoiar a recuperação rápida e ajudar a desenvolver o seu plano de DR.

O Azure DocumentDB não oferece failover automático ou recuperação de desastres incorporada. Planejar a alta disponibilidade é uma etapa crítica à medida que sua solução é dimensionada.

Recuperação de desastres em geografia de uma única região

Para maximizar o seu tempo de atividade, planeie com antecedência para manter a continuidade do negócio e prepare-se para a recuperação de desastres com o Azure DocumentDB.

Embora os serviços do Azure sejam projetados para maximizar o tempo de atividade, podem ocorrer interrupções de serviço não planejadas. Um plano de recuperação de desastres garante que você tenha uma estratégia em vigor para lidar com interrupções de serviço regionais.

O Azure DocumentDB faz automaticamente cópias de segurança dos seus dados a intervalos regulares. As cópias de segurança automáticas são feitas sem afetar o desempenho ou a disponibilidade das operações da base de dados. Todos os backups são realizados automaticamente em segundo plano e armazenados separadamente dos dados de origem em um serviço de armazenamento. Esses backups automáticos são úteis em cenários em que você exclui ou modifica recursos acidentalmente e depois requer as versões originais.

Os backups automáticos são mantidos em vários intervalos com base no fato de o cluster estar ativo no momento ou ter sido excluído recentemente.

Período de retenção
Clusters ativos 35 dias
Clusters excluídos 7 dias

Design para alta disponibilidade

A alta disponibilidade (HA) deve estar ativada para clusters críticos do Azure DocumentDB a executar cargas de trabalho de produção. Em um cluster com suporte a HA, cada fragmento serve como primário, além de um fragmento de espera ativa provisionado em outra zona de disponibilidade. A replicação entre o estilhaço primário e o secundário é síncrona por padrão. Qualquer modificação no banco de dados é mantida nos fragmentos primário e secundário (espera ativa) antes que uma resposta do banco de dados seja recebida.

O serviço mantém verificações de integridade e pulsações para cada fragmento primário e secundário do cluster. Se um fragmento primário ficar indisponível devido a uma interrupção regional ou de zona, o fragmento secundário é automaticamente promovido para se tornar o novo primário e um fragmento secundário subsequente é construído para o novo primário. Além disso, se um fragmento secundário ficar indisponível, o serviço criará automaticamente um novo fragmento secundário com uma cópia completa dos dados do primário.

Se o serviço acionar um failover do fragmento primário para o secundário, as conexões serão redirecionadas de forma transparente para o novo fragmento primário.

A replicação síncrona entre os fragmentos primário e secundário garante que não haja perda de dados se houver um failover.

Próximos passos

  • Last updated on