Alta disponibilidade no Azure Cosmos DB para MongoDB vCore
APLICA-SE A: 
MongoDB vCore
A alta disponibilidade (HA) na região evita o tempo de inatividade do banco de dados mantendo réplicas em espera de cada fragmento em um cluster. Se um fragmento deixar de responder por qualquer motivo, o Azure Cosmos DB para MongoDB vCore alternará as conexões de entrada do fragmento com falha para seu modo de espera. Quando o failover acontece, os fragmentos promovidos sempre têm dados atualizados por meio da replicação síncrona.
Todos os fragmentos primários em um cluster são provisionados em uma zona de disponibilidade (AZ) para melhor latência entre os fragmentos. Os fragmentos de espera são provisionados em outra zona de disponibilidade.
Mesmo sem HA habilitada, cada fragmento tem seu próprio LRS (armazenamento com redundância local) com três réplicas síncronas mantidas pelo serviço de Armazenamento do Azure. Todas as três réplicas estão localizadas na região do Azure do cluster. Se houver uma única falha de réplica, o serviço de Armazenamento do Azure a detetará e recriará a réplica com falha de forma transparente. Consulte as métricas nesta página para a durabilidade do armazenamento LRS.
Quando a HA está habilitada, o Azure Cosmos DB para MongoDB vCore executa um fragmento em espera para cada fragmento primário no cluster. Cada fragmento primário e de espera tem a mesma configuração de computação e armazenamento. O primário e seu modo de espera usam replicação síncrona. Esse tipo de replicação permite que você tenha sempre os mesmos dados nos fragmentos primário e em espera no cluster. Em resumo, nosso serviço deteta uma falha nos fragmentos primários e faz failover para fragmentos em espera com perda de dados zero.
A cadeia de conexão de cluster permanece sempre a mesma, independentemente dos failovers. Isso permite que o serviço abstraia alterações em fragmentos físicos que atendem solicitações de aplicativos.
Quando a alta disponibilidade na região é habilitada no cluster, cada fragmento de cluster é coberto pelo SLA (Service Level Agreement, contrato de nível de serviço) de 99,99% para disponibilidade.
A alta disponibilidade pode ser habilitada no momento da criação do cluster. A alta disponibilidade também pode ser habilitada e desabilitada a qualquer momento em um cluster vCore do Azure Cosmos DB para MongoDB existente. Não há tempo de inatividade do banco de dados quando a alta disponibilidade é habilitada ou desabilitada em um cluster vCore do Azure Cosmos DB para MongoDB.
O que acontece durante um failover
Cada failover de estilhaço consiste em três fases: deteção de indisponibilidade, alternar para o fragmento em espera e recriação do fragmento em espera. O serviço executa o monitoramento contínuo da disponibilidade para cada fragmento primário e em espera no cluster fazendo verificação periódica de integridade. Quando a verificação de integridade indica de forma confiável que o fragmento parou de responder e precisa ser declarado como falha, o failover real (switch) para o estilhaço em espera é iniciado.
Durante a fase de comutação, as leituras e gravações do banco de dados são redirecionadas para o fragmento em espera. A replicação síncrona entre cada fragmento primário e em espera garante que o fragmento em espera tenha sempre o mesmo conjunto de dados que o principal. Isso permite que todos os failovers sejam executados com perda de dados zero. A mudança para o modo de espera é feita sem tempo de inatividade para leituras. As operações de gravação podem exigir novas tentativas de serviço interno durante a fase de comutação. Essas novas tentativas podem ser vistas como lentidão de gravação no lado do aplicativo.
Quando o failover de estilhaço for concluído, o cluster estará totalmente operacional. A última etapa para retornar à configuração original altamente disponível é recriar o fragmento de espera. Essa recriação de estilhaços em standby é realizada sem tempo de inatividade ou impacto no desempenho do fragmento principal.