Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Importante
O Azure Cosmos DB para PostgreSQL não tem mais suporte para novos projetos. Não use este serviço para novos projetos. Em vez disso, use um destes dois serviços:
Use o Azure Cosmos DB para NoSQL para obter uma solução de banco de dados distribuído projetada para cenários de alta escala com um SLA (contrato de nível de serviço) de disponibilidade de 99.999%, dimensionamento automático instantâneo e failover automático em várias regiões.
Use a funcionalidade de Clusters Elásticos do Azure para PostgreSQL para PostgreSQL fragmentado, utilizando a extensão Citus de código aberto.
A alta disponibilidade (HA) minimiza o tempo de inatividade do banco de dados mantendo réplicas de contingência de cada nó num cluster. Se um nó ficar inativo, o Azure Cosmos DB for PostgreSQL redireciona as conexões de entrada do nó com falha para o seu nó de contingência. A ativação pós-falha ocorre após alguns minutos e os nós promovidos têm sempre dados atualizados através da replicação da transmissão em fluxo síncrona do PostgreSQL.
Todos os nós primários em um cluster são provisionados em uma zona de disponibilidade para melhor latência entre os nós. A zona de disponibilidade preferencial permite colocar todos os nós do cluster na mesma zona de disponibilidade em que o aplicativo é implantado. Essa proximidade pode melhorar ainda mais o desempenho, diminuindo a latência do banco de dados do aplicativo. Os nós em espera são provisionados em outra zona de disponibilidade. O portal do Azure exibe a zona de disponibilidade de cada nó primário em um cluster. Você também pode verificar a zona de disponibilidade de cada nó num cluster usando um dos métodos programáticos, como REST APIs.
Mesmo sem HA habilitada, cada nó 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. Se houver uma única falha de réplica, ela será detetada pelo serviço de Armazenamento do Azure e recriada de forma transparente. Para a durabilidade do armazenamento LRS, consulte as métricas nesta página.
Quando a HA está habilitada, o Azure Cosmos DB para PostgreSQL executa um nó em espera para cada nó primário no cluster. O primário e o standby utilizam replicação síncrona do PostgreSQL. Essa replicação permite que os clientes tenham um tempo de inatividade previsível se um nó principal falhar. Em resumo, o nosso serviço detecta uma falha nos nós primários e atua com failover para nós de reserva sem perda de dados.
Para aproveitar o HA no nó coordenador, os aplicativos de banco de dados precisam detetar e repetir conexões descartadas e transações com falha. O coordenador recém-promovido está acessível através da mesma string de conexão.
Estados de alta disponibilidade
A recuperação pode ser dividida em três estágios: deteção, failover e recuperação completa. O Azure Cosmos DB para PostgreSQL executa verificações periódicas de integridade em cada nó e, após quatro verificações com falha, determina que um nó está inativo. Em seguida, o Azure Cosmos DB para PostgreSQL promove um estado de espera para o nó primário (failover) e cria um novo modo de espera. A replicação de streaming começa, trazendo o novo nó para o estado mais recente. Quando todos os dados tenham sido replicados, o nó terá alcançado a recuperação total.
O Azure Cosmos DB para PostgreSQL exibe o progresso do failover na página de Visão geral de clusters no portal do Azure.
- Íntegro: o HA está habilitado e o nó é totalmente replicado para seu modo de espera.
- Failover em andamento: uma falha foi detectada no nó primário e um failover para o estado de espera foi iniciado. Esse estado transita para Criar modo de espera assim que o failover para o nó de espera é concluído e o modo de espera se torna o novo primário.
- Criação de standby: O standby anterior foi promovido para primário e um novo standby está sendo criado para ele. Quando o novo secundário estiver pronto, esse estado será transferido para a Replicação em andamento.
- Replicação em progresso: o novo nó de espera é provisionado e a sincronização de dados está em progresso. Depois de todos os dados serem replicados para o novo standby, a replicação síncrona é habilitada entre os nós primário e standby, e os estados dos nós revertem para o estado Saudável.
- Não: a HA não está habilitada neste nó.
Próximos passos
- Saiba como habilitar a alta disponibilidade em um cluster.
- Saiba mais sobre as zonas de disponibilidade no Azure Cosmos DB para PostgreSQL.