Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 shard se tornar não responsivo por qualquer motivo, o Azure DocumentDB alternará as conexões recebidas do shard com falha para o seu Em espera. Quando ocorre o 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 AZ (zona de disponibilidade) para obter uma latência melhor entre os fragmentos. Os fragmentos em espera são provisionados em outra zona de disponibilidade.
Mesmo sem a 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 onde o cluster está localizado. Se houver uma única falha de réplica, o serviço de Armazenamento do Azure a detectará e recria de forma transparente a réplica com falha. Consulte as métricas nesta página para obter a durabilidade do armazenamento LRS.
Quando a HA está habilitada, o Azure DocumentDB 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 sua réplica em espera usam replicação síncrona. Esse 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 de 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% 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 do Azure DocumentDB existente. Não há tempo de inatividade do banco de dados quando a alta disponibilidade está habilitada ou desabilitada em um cluster do Azure DocumentDB.
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 troca, 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.