Alta disponibilidade em Banco de Dados do Azure para PostgreSQL – Hiperescala (Citus)

A HA (alta disponibilidade) evita o tempo de inatividade no banco de dados mantendo réplicas em espera de cada nó em um grupo de servidores. Se um nó falhar, o Hiperescala (Citus) alterna as conexões de entrada do nó com falha para o modo em espera. O failover ocorre em alguns minutos e os nós promovidos sempre têm dados atualizados por meio de streaming de replicação síncrona do PostgreSQL.

Mesmo sem HA habilitada, cada nó Hiperescala (Citus) 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 falha de réplica única, ela será detectada pelo serviço de Armazenamento do Azure e será criada de forma transparente. Para durabilidade do armazenamento LRS, consulte métricas nesta página.

Quando a HA está habilitada, Hiperescala (Citus) executa um nó em espera para cada nó primário no grupo de servidores. O primário e seu modo de espera usam a replicação síncrona do PostgreSQL. Essa replicação permite que os clientes tenham tempo de inatividade previsível se um nó primário falhar. Em resumo, nosso serviço detecta uma falha em nós primários e faz o failover para nós em espera sem perda de dados.

Afim de aproveitar a HA no nó de coordenador, os aplicativos de banco de dados precisam detectar e repetir conexões descartadas e transações com falha. Será possível acessar o coordenador recém-promovido com a mesma cadeia de conexão.

Estados de alta disponibilidade

A recuperação pode ser dividida em três estágios: detecção, failover e recuperação completa. A Hiperescala (Citus) executa verificações de integridade periódicas em cada nó e após quatro verificações com falha ele determina que um nó está inoperante. Em seguida, a Hiperescala (Citus) promove um modo de espera para o status do nó primário (failover) e provisiona uma nova espera. A replicação de streaming começa, atualizando o novo nó. Quando todos os dados forem replicados, o nó atingirá a recuperação completa.

Hiperescala (Citus) exibe seu estado de progresso de failover na página Visão geral para grupos de servidores no portal do Azure.

  • Íntegra: a HA está habilitada 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 em espera foi iniciado. Esse estado fará a transição para Criando nó em espera depois que o failover para o nó em espera for concluído e esse nó em espera se tornará o novo primário.
  • Criando nó em espera: o nó em espera anterior foi promovido para primário, e um novo nó em espera está sendo criado para ele. Quando o novo secundário estiver pronto, esse estado fará a transição para 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 a nova espera, a replicação síncrona será habilitada entre os nós primário e em espera, e o estado dos nós fará a transição de volta para Íntegro.
  • Não: a HA não está habilitada neste nó.

Próximas etapas