Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo discute a recuperação de desastres (DR) entre regiões para Azure DocumentDB. Ele também abrange as capacidades de leitura dos clusters de réplica nas mesmas ou noutras regiões do Azure para escalabilidade de operações de leitura.
O recurso de replicação permite replicar dados de um cluster para um cluster somente leitura em outra ou na mesma região do Azure. As réplicas são atualizadas com a tecnologia de replicação assíncrona. Pode ter uma réplica de cluster noutra região de escolha para o cluster principal do Azure DocumentDB. Em um caso raro de interrupção de região, você pode promover a réplica de cluster em outra região para se tornar o novo cluster de leitura-gravação para operação contínua do banco de dados MongoDB. Os aplicativos podem continuar a usar as mesmas cadeias de conexão depois que a réplica de cluster em outra região for promovida para se tornar o novo cluster primário.
As réplicas são novos clusters que pode gerir de forma semelhante aos clusters normais. Para cada réplica de leitura, são-lhe faturados a computação aprovisionada nos vCores e o armazenamento em GiB/mês. Os custos de computação e armazenamento para clusters de réplica têm a mesma estrutura que os clusters regulares e os preços da região do Azure onde são criados.
Recuperação de desastres usando clusters réplica
A replicação entre regiões é um dos vários pilares importantes na estratégia BCDR (continuidade de negócios e recuperação de desastres) do Azure. A replicação entre regiões replica de forma assíncrona os mesmos aplicativos e dados em outras regiões do Azure para proteção de recuperação de desastres. Nem todos os serviços do Azure replicam dados automaticamente ou retornam automaticamente de uma região com falha para replicação cruzada para outra região habilitada. O Azure DocumentDB oferece a opção de criar uma réplica de cluster noutra região e replicar automaticamente os dados escritos no cluster primário para essa réplica. O fallback para a réplica do cluster se houver uma interrupção na região primária precisa ser iniciado manualmente.
Quando a replicação entre regiões está ativada num cluster Azure DocumentDB, cada fragmento é replicado continuamente para outra região. Essa replicação mantém uma réplica de dados na região selecionada. Essa réplica está pronta para ser usada como parte do plano de recuperação de desastres em um caso raro de interrupção da região primária. A replicação é assíncrona. As operações de gravação no fragmento do cluster primário não esperam pela conclusão da replicação no fragmento correspondente da réplica antes de enviar a confirmação de uma gravação bem-sucedida. A replicação assíncrona ajuda a evitar latências maiores para operações de gravação no cluster primário.
Gravações contínuas, operações de leitura em réplicas de cluster e cadeias de conexão
A cadeia global de conexão de leitura-escrita no Azure DocumentDB direciona consistentemente as escritas para o cluster ativo com capacidade de escrita. Quando o utilizador inicia uma promoção de cluster de réplica, o cluster de réplica na Região B é alterado para modo de escrita, enquanto o cluster primário original na Região A é definido para leitura apenas. Antes da promoção, a cadeia de conexão global de leitura-escrita está definida para o cluster primário na Região A e, em seguida, é atualizada para apontar para a Região B quando esta assume responsabilidades de escrita. Para aplicações que utilizam a cadeia de conexão global de leitura-escrita, as operações de escrita continuam sem interrupções durante todo o processo de promoção, mantendo o fluxo de dados contínuo.
Clusters de réplica também estão disponíveis para leitura. Ele ajuda a descarregar operações de leitura intensivas do cluster primário ou fornecer latência reduzida para operações de leitura para os clientes localizados mais próximos da região de replicação. Quando a replicação entre regiões está habilitada, os aplicativos podem usar a cadeia de autoconexão do cluster de réplica para executar leituras da réplica do cluster. O cluster primário está disponível para operações de leitura e gravação usando sua própria cadeia de conexão automática.
Quando você cria uma réplica habilitando a replicação entre regiões ou a mesma região, ela não herda configurações de rede, como regras de firewall do cluster primário. Essas configurações devem ser configuradas independentemente para a réplica. A réplica herda a conta de administrador do cluster primário. As contas de usuário precisam ser gerenciadas no cluster primário. Você pode se conectar ao cluster primário e seu cluster de réplica usando as mesmas contas de usuário.
Promoção de cluster de réplica
Se ocorrer uma interrupção de região, você poderá executar a operação de recuperação de desastres promovendo a réplica do cluster em outra região para ficar disponível para gravações. Durante a operação de promoção de réplicas, estas etapas estão acontecendo:
- As gravações na réplica na região B são habilitadas, em adição às leituras. A réplica anterior transforma-se num novo cluster de leitura e gravação.
- O cluster de réplica promovido na região B aceita operações de escrita usando a sua string de conexão e a string de conexão global de leitura-escrita.
- O cluster na região A é definido como somente leitura e mantém sua cadeia de conexão.
Importante
Como a replicação é assíncrona, alguns dados do cluster na região A podem não ser replicados para a região B quando a réplica do cluster na região B é promovida. Em caso afirmativo, a elevação resultaria nos dados não replicados não estarem presentes em ambos os clusters.
Métodos de autenticação em clusters de réplica
Os métodos de autenticação são geridos independentemente nos clusters primário e réplica. Os usuários e outras entidades de segurança, como identidades gerenciadas, são sempre gerenciados no cluster primário e sincronizados com o cluster de réplica.
Se o cluster primário tiver o método de autenticação nativo do Banco de Dados de Documentos desabilitado no momento em que o cluster de réplica for criado, não será permitido habilitar a autenticação nativa do Banco de Dados de Documentos na réplica. Para habilitar a autenticação nativa do Banco de Dados de Documentos em tal réplica, ela deve primeiro ser promovida.
Conteúdo relacionado
- Saiba como habilitar a replicação e promover o cluster de réplica
- Consulte os limites e limitações de replicação
- Para resolver um problema com a replicação entre regiões, consulte este guia de solução de problemas.
- Aprenda sobre fiabilidade no Azure DocumentDB