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.
A alta disponibilidade (HA) dentro da região evita o tempo de inatividade da base de dados ao manter réplicas de espera de cada fragmento num cluster. Se um shard deixar de responder por qualquer motivo, o Azure DocumentDB alterna as ligações recebidas do shard falhado para o seu standby. Quando ocorre failover, os shards promovidos têm sempre dados atualizados através de replicação síncrona.
Todos os shards primários de um cluster são provisionados em uma zona de disponibilidade (AZ) para otimizar a latência entre eles. Os fragmentos de reserva são aprovisionados para outra zona de disponibilidade.
Mesmo sem o HA ativado, cada shard tem o seu próprio armazenamento localmente redundante (LRS) com três réplicas síncronas mantidas pelo serviço Azure Storage. As três réplicas estão localizadas na região Azure do cluster. Se houver uma única falha de réplica, o serviço de armazenamento do Azure deteta-a e recria de forma transparente a réplica falhada. Consulte métricas nesta página para a durabilidade do armazenamento LRS.
Quando o HA está ativado, o Azure DocumentDB executa um shard de espera para cada shard primário no cluster. Cada shard primário e de reserva tem a mesma configuração de computação e armazenamento. O primário e o seu standby utilizam replicação síncrona. Este tipo de replicação permite-te ter sempre os mesmos dados nos shards primários e de espera no teu cluster. Em resumo, o nosso serviço deteta uma falha nos shards primários e realiza uma transferência automática para shards de reserva sem qualquer perda de dados.
A cadeia de ligação do cluster mantém-se sempre a mesma, independentemente dos failovers. Isso permite ao serviço abstrair alterações nos shards físicos que servem solicitações de aplicações.
Quando a alta disponibilidade dentro da região está ativada no cluster, cada fragmento do cluster é coberto pelo acordo de nível de serviço (SLA) de 99,99% para disponibilidade.
A alta disponibilidade pode ser ativada no momento da criação do cluster. A alta disponibilidade também pode ser ativada e desativada a qualquer momento num cluster Azure DocumentDB existente. Não há tempo de inatividade na base de dados quando a alta disponibilidade está ativada ou desativada num cluster Azure DocumentDB.
O que acontece durante um failover
Cada failover de fragmento consiste em três fases: deteção de estado de não disponibilidade, mudança para o fragmento de espera e recriação do fragmento de espera. O serviço efetua monitorização contínua da disponibilidade de cada shard primário e secundário no cluster, realizando verificações periódicas do estado. Quando a verificação de saúde indica de forma fiável que o fragmento deixou de responder e precisa de ser declarado falhado, inicia-se o failover real (switch) para o fragmento de espera.
Durante a fase de comutação, as leituras e escritas da base de dados são redirecionadas para o shard de espera. A replicação síncrona entre cada fragmento primário e de espera garante que o fragmento de reserva tenha sempre o mesmo conjunto de dados que o seu primário. Isso permite que todos os failovers sejam realizados sem perda de dados. A mudança para standby é feita sem interrupção nas leituras. As operações de escrita podem exigir repetições internas do serviço durante a fase de transição. Estas tentativas podem ser vistas como lentidão de escrita do lado da aplicação.
Assim que o failover do fragmento estiver concluído, o cluster estará totalmente operacional. O último passo para regressar à configuração de alta disponibilidade original é recriar o shard de standby. Esta recriação do fragmento de reserva é realizada sem tempo de inatividade ou impacto de desempenho no fragmento primário.