Condividi tramite

Disponibilità elevata in Azure Cosmos DB for PostgreSQL

  • Articolo

SI APPLICA A: Azure Cosmos DB for PostgreSQL (con tecnologia basata sull'estensione di database Citus per PostgreSQL)

La disponibilità elevata riduce al minimo i tempi di inattività del database mantenendo le repliche di standby di ogni nodo in un cluster. Se un nodo diventa inattivo, Azure Cosmos DB for PostgreSQL passa le connessioni in ingresso dal nodo in errore al relativo standby. Il failover viene eseguito entro pochi minuti e i nodi promossi hanno sempre a disposizione dati aggiornati grazie alla replica di streaming sincrona di PostgreSQL.

Viene effettuato il provisioning di tutti i nodi primari in un cluster in un'unica zona di disponibilità per una migliore latenza tra i nodi. La zona di disponibilità preferita consente di inserire tutti i nodi del cluster nella stessa zona di disponibilità in cui viene distribuita l'applicazione. Questa prossimità potrebbe migliorare ulteriormente le prestazioni riducendo la latenza di app-database. Viene effettuato il provisioning dei nodi di standby in un'altra zona di disponibilità. Il portale di Azure visualizza la zona di disponibilità di ogni nodo primario in un cluster. Inoltre è possibile controllare la zona di disponibilità di ogni nodo in un cluster usando uno dei metodi programmatici, ad esempio le API REST.

Anche senza disponibilità elevata abilitata, ogni nodo ha una propria archiviazione con ridondanza locale con tre repliche sincrone gestite dal servizio Archiviazione di Azure. Se si verifica un errore di replica singola, viene rilevato dal servizio Archiviazione di Azure e viene ricreato in modo trasparente. Per la durabilità dell'archiviazione con ridondanza locale, vedere metriche in questa pagina.

Quando la disponibilità elevata è abilitata, Azure Cosmos DB for PostgreSQL esegue un nodo di standby per ciascun nodo primario nel cluster. Il database primario e il relativo standby usano la replica PostgreSQL sincrona. Questa replica consente ai clienti di avere tempi di inattività prevedibili in caso di errore di un nodo primario. In breve, il servizio rileva un errore nei nodi primari ed esegue il failover nei nodi di standby senza perdita di dati.

Per sfruttare la disponibilità elevata nel nodo coordinatore, le applicazioni di database devono rilevare e ripetere le connessioni rimosse e le transazioni non riuscite. Il coordinatore appena alzato di livello è accessibile con la stessa stringa di connessione.

Stati di disponibilità elevata

Il ripristino può essere suddiviso in tre fasi: rilevamento, failover e recupero completo. Azure Cosmos DB for PostgreSQL esegue controlli di integrità periodici su ogni nodo e dopo quattro controlli non riusciti determina che un nodo è inattivo. Azure Cosmos DB for PostgreSQL promuove quindi lo stato del nodo primario (failover) e crea una nuova modalità standby-to-be. La replica di flusso inizia, portando il nuovo nodo aggiornato. Quando tutti i dati sono stati replicati, il nodo ha raggiunto il recupero completo.

Azure Cosmos DB for PostgreSQL visualizza lo stato di avanzamento del failover nella pagina di Panoramica per i cluster nel portale di Azure.

  • Integro: la disponibilità elevata è abilitata e il nodo viene completamente replicato in standby.
  • Failover in corso: è stato rilevato un errore nel nodo primario ed è stato avviato un failover in standby. Una volta completato il failover nel nodo standby, avviene una transizione di stato in Creazione standby e lo standby diventa il nuovo primario.
  • Creazione standby: lo standby precedente è stato alzato di livello a primario e viene creato un nuovo standby. Quando il nuovo secondario è pronto, la transizione di stato passa a Replica in corso.
  • Replica in corso: viene effettuato il provisioning del nuovo nodo standby e la sincronizzazione dei dati è in corso. Dopo che tutti i dati vengono replicati nel nuovo standby, la replica sincrona viene abilitata tra i nodi primario e standby e la transizione di stato dei nodi i torna a Integro.
  • No: la disponibilità elevata non è abilitata in questo nodo.

Passaggi successivi