Alta disponibilidade no vCore do Azure Cosmos DB for MongoDB

APLICA-SE AO: 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 ficar sem resposta por qualquer motivo, o Azure Cosmos DB for MongoDB vCore alterna as conexões de entrada do fragmento com falha para em espera. Quando ocorre failover, os fragmentos promovidos sempre têm dados novos por meio de replicação síncrona.

Todos os fragmentos primários em um cluster são provisionados em uma zona de disponibilidade (AZ) para obter uma latência melhor entre os fragmentos. Os fragmentos em 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 Microsoft 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 Microsoft Azure a detectará e recriará de forma transparente a réplica com falha. Confira as métricas nesta página para ver a durabilidade do armazenamento LRS.

Quando a HA está habilitada, o Azure Cosmos DB for MongoDB vCore executa um fragmento em espera para cada fragmento primário no cluster. Cada fragmento primário e em espera tem a mesma configuração de computação e armazenamento. O primário e o seu modo de espera usam replicação síncrona. Este tipo de replicação permite que você sempre tenha os mesmos dados nos fragmentos primário e em espera em seu cluster. Em poucas palavras, nosso serviço detecta uma falha em fragmentos primários e faz failover para fragmentos em espera sem perda de dados.

A cadeia de conexão de cluster sempre permanece a mesma, independentemente dos failovers. Isso permite que o serviço abstraia as 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 (contrato de nível de serviço) de 99,99% de 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 existente do Azure Cosmos DB for MongoDB vCore. Não há tempo de inatividade do banco de dados quando a alta disponibilidade está habilitada ou desabilitada em um cluster do Azure Cosmos DB for MongoDB vCore.

O que acontece durante um failover

Cada failover de fragmento consiste em três fases: detecção de indisponibilidade, alternância 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 uma verificação periódica de integridade. Quando a verificação de integridade indica de forma confiável que o fragmento não respondeu e precisa ser declarado com falha, o failover real (comutador) para o fragmento em espera é iniciado.

Durante a fase de comutador, 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 sempre tenha o mesmo conjunto de dados que o principal. Isso permite que todos os failovers sejam executados sem perda de dados. A opção para espera é feita sem tempo de inatividade para leituras. As operações de gravação podem exigir novas tentativas de serviço internas durante a fase de comutador. Essas repetições podem ser percebidas como lentidão de gravação no lado do aplicativo.

Depois que o failover do fragmento for concluído, o cluster estará totalmente operacional. A última etapa para retornar à configuração original altamente disponível é recriar o fragmento em espera. Esta recriação de fragmento em espera é executada sem o tempo de inatividade ou o impacto no desempenho no fragmento primário.