Alzare di livello le repliche di lettura nel server flessibile di Database di Azure per PostgreSQL

Il termine alzare di livello fa riferimento al processo in cui viene indicato a una replica di terminare la modalità di replica stessa e passare a operazioni di lettura/scrittura complete.

È possibile alzare di livello le repliche in due modi diversi:

Alzare di livello al server primario

Questa azione eleva una replica al ruolo del server primario. Nel processo, il server primario corrente viene abbassato di livello a un ruolo di replica, scambiandone i ruoli. Per eseguire correttamente una promozione, è necessario configurare un endpoint virtuale sia per il primario corrente come endpoint di scrittura, sia per la replica destinata alla promozione come endpoint di lettura. L'innalzamento di livello ha esito positivo solo se la replica di destinazione è inclusa nella configurazione dell'endpoint lettore. Un utente con l'autorizzazione Microsoft.DBforPostgreSQL/servers/write nel server di origine può eseguire l'operazione di switchover.

Se sul server primario sono presenti repliche danneggiate, rimuovi tali repliche prima di avviare l'azione di promozione a server primario. Durante questo processo, la replica di lettura viene alzata di livello a nuovo server primario. Questa operazione potrebbe causare una breve interruzione del servizio di circa 1–3 minuti, a seconda del ritardo della replica al momento della promozione (per le promozioni pianificate). Al termine della promozione, il server primario precedente viene riconfigurato per funzionare come replica di lettura.

Il diagramma seguente illustra la configurazione dei server prima dell'innalzamento di livello e lo stato risultante dopo il completamento dell'operazione di promozione.

Alzare di livello a un server indipendente e rimuovere dalla replica

Quando si sceglie questa opzione, la replica viene alzata di livello per diventare un server indipendente e viene quindi rimossa dal processo di replica. Di conseguenza, sia il server primario che quello alzato di livello funzionano come due server di lettura/scrittura indipendenti. Sebbene sia possibile configurare gli endpoint virtuali, non sono necessari per questa operazione. Il server appena alzato di livello non fa più parte di alcun endpoint virtuale esistente, anche se in precedenza l'endpoint lettore puntava a esso. Aggiorna la stringa di connessione dell'applicazione in modo che punti alla replica appena promossa, se l'applicazione deve connettersi a essa.

Il diagramma seguente illustra come vengono configurati i server prima di essere alzati di livello e la relativa configurazione dopo aver completato correttamente la creazione di server indipendenti.

Per entrambi i metodi di promozione, prendere in considerazione queste opzioni:

• Pianificato: questa opzione garantisce che i dati vengano sincronizzati prima dell'innalzamento di livello. Applica tutti i log in sospeso per garantire la coerenza dei dati prima di accettare le connessioni client.

• Forzato: questa opzione è progettata per il ripristino rapido in scenari come interruzioni a livello di area. Invece di attendere la sincronizzazione di tutti i dati dal server primario, il server diventa operativo quando elabora i file WAL necessari per ottenere lo stato coerente più vicino. Se si alza di livello la replica usando questa opzione, il ritardo al momento in cui si scollega la replica dal database primario indica la quantità di dati persi.

Informazioni su come alzare di livello la replica a server primario e promuovere il server indipendente e rimuoverlo dalla replica.

Gestione della configurazione

Il piano di controllo considera le repliche di lettura come server separati, in modo da gestire le configurazioni in modo indipendente. Questo approccio offre flessibilità per gli scenari di scalabilità in lettura. Tuttavia, quando si usano repliche per il ripristino di emergenza, è necessario assicurarsi che la configurazione sia quella desiderata.

L'operazione di promozione non include configurazioni e parametri specifici. Ecco alcuni dei principali:

• PgBouncer: le impostazioni e lo stato del pooler di connessioni predefiniti pgBouncer non vengono replicati durante il processo di innalzamento di livello. Se hai abilitato PgBouncer sul primario ma non sulla replica, rimane disabilitato sulla replica dopo la promozione. Per usare PgBouncer nel server appena alzato di livello, è necessario abilitarlo prima o dopo l'azione di promozione.
• Archivio di backup con ridondanza geografica: le impostazioni di backup geografico non vengono trasferite. Poiché per le repliche non può essere abilitato il backup geografico, il database primario promosso (in precedenza la replica) non lo ha dopo la promozione. È possibile attivare la funzionalità solo quando si crea il server standard (non una replica).
• Parametri: se i valori differiscono per la replica primaria e di lettura, non cambiano durante l'innalzamento di livello. I parametri che influiscono sulle dimensioni della memoria condivisa devono avere gli stessi valori nelle repliche e primarie. Questo requisito è dettagliato nella sezione Parametri .
• Autenticazione di Microsoft Entra: se il server primario ha configurato l'autenticazione di Microsoft Entra, ma la replica usa l'autenticazione PostgreSQL, la promozione non passa automaticamente la replica all'autenticazione di Microsoft Entra. La replica mantiene l'autenticazione PostgreSQL. È necessario configurare manualmente l'autenticazione di Microsoft Entra sulla replica promossa, prima o dopo il processo di promozione.
• Disponibilità elevata :se è necessaria una disponibilità elevata dopo la promozione, è necessario configurarla nel server primario appena alzato di livello, in seguito all'inversione del ruolo.

Considerazioni

Stati del server durante l'innalzamento di livello

Negli scenari di innalzamento di livello pianificato e forzato i server (sia primari che di replica) devono trovarsi in uno stato Pronto . Se lo stato di un server è diverso da Pronto ( ad esempio Aggiornamento o Riavvio), la promozione in genere non può procedere senza problemi. Tuttavia, viene fatta un'eccezione nel caso di interruzioni a livello di area.

Durante tali interruzioni a livello di area, è possibile implementare il metodo di innalzamento di livello forzato indipendentemente dallo stato corrente del server primario. Questo approccio consente un'azione rapida in risposta a potenziali emergenze a livello di area, ignorando i controlli normali sulla disponibilità del server.

In caso di problemi del server primario precedente oltre il ripristino durante la promozione della replica, l'unica opzione consiste nell'eliminare il server primario precedente e creare nuovamente il server di replica.

Visibilità di più repliche durante l'innalzamento di livello in aree non abbinate

Quando si gestiscono più repliche e l'area geografica primaria non dispone di un'area geografica associata, sono necessarie considerazioni particolari. Se un'interruzione a livello di area geografica interessa il database primario, la replica appena promossa non riconosce automaticamente altre repliche. Anche se è ancora possibile indirizzare le applicazioni alla replica promossa per garantire la continuità operativa, le repliche non riconosciute rimangono disconnesse durante l'interruzione. Queste repliche aggiuntive riassociano e riprendono i ruoli solo dopo il ripristino dell'area primaria originale.

Ripristino temporizzato durante la promozione

Negli scenari di promozione pianificata e forzata, i backup automatizzati più recenti devono essere disponibili per garantire che le operazioni di ripristino temporizzato siano riuscite. Esiste un problema noto per cui l'operazione PITR potrebbe generare il seguente errore dopo le operazioni di failover e failback. La soluzione di questo problema è pianificata in una versione futura. Per garantire la corretta esecuzione delle operazioni PITR fino al momento più recente possibile, attendere il completamento del backup automatico dopo un'operazione di promozione.

Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.

Domande frequenti

• È possibile alzare di livello una replica se il server primario ha la disponibilità elevata abilitata?

  Sì, se il server primario è abilitato o meno per la disponibilità elevata, è possibile alzarne di livello la replica in lettura. La possibilità di alzare di livello una replica di lettura a un server primario è indipendente dalla configurazione a disponibilità elevata del database primario.

• Se ho un'istanza primaria con HA abilitata e una replica di lettura, e promuovo la replica per poi tornare all'istanza primaria originale, il server è ancora in HA?

  No, il processo di promozione disabilita HA perché Azure Database per PostgreSQL non supporta le repliche di lettura con HA abilitata. Promuovere una replica di lettura in un database primario significa che il ruolo primario originale cambia in una replica. Se si torna indietro, è necessario abilitare la disponibilità elevata nel server primario originale.

Contenuti correlati

• Repliche in lettura in Database di Azure per PostgreSQL.
• Replica geografica in Database di Azure per PostgreSQL.
• Endpoint virtuali per le repliche in lettura in Database di Azure per PostgreSQL.
• Creare una replica in lettura.
• Replica tra aree di Azure e reti virtuali con rete privata.