Elevada disponibilidade no Azure Cosmos DB for PostgreSQL

  • Artigo

APLICA-SE A: Azure Cosmos DB para PostgreSQL (alimentado pela extensão de banco de dados Citus para PostgreSQL)

A alta disponibilidade (HA) minimiza o tempo de inatividade do banco de dados mantendo réplicas em espera de cada nó em um cluster. Se um nó ficar inativo, o Azure Cosmos DB for PostgreSQL muda as ligações de entrada do nó com falha para a reserva. 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ó em um cluster usando um dos métodos programáticos, como APIs REST.

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 seu modo de espera usam replicação PostgreSQL síncrona. Essa replicação permite que os clientes tenham um tempo de inatividade previsível se um nó principal falhar. Em resumo, nosso serviço deteta uma falha nos nós primários e faz failover para nós em espera com perda de dados zero.

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 é acessível com a mesma cadeia 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, atualizando o novo nó. Quando todos os dados tiverem sido replicados, o nó alcançará a recuperação total.

O Azure Cosmos DB para PostgreSQL exibe seu estado de progresso de failover na página 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 detetada no nó primário e um failover para 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 andamento: o novo nó em espera é provisionado e a sincronização de dados está em andamento. Depois que todos os dados são replicados para o novo modo de espera, a replicação síncrona é habilitada entre os nós primário e em espera, e as transições de estado dos nós voltam para Íntegro.
  • 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.