Alzare di livello le repliche in lettura in Database di Azure per PostgreSQL - Server flessibile

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

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.

L'innalzamento di livello delle repliche può essere eseguito in due modi distinti:

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 una promozione riuscita, è necessario avere un endpoint virtuale configurato sia per l'endpoint primario corrente come endpoint writer che per la replica destinata alla promozione come endpoint lettore. L'innalzamento di livello ha esito positivo solo se la replica di destinazione è inclusa nella configurazione dell'endpoint lettore.

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

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. Si noti che, mentre gli endpoint virtuali possono essere configurati, 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. Pertanto, è essenziale aggiornare la stringa di connessione dell'applicazione per indirizzarla alla replica appena promossa se l'applicazione deve connettersi.

Il diagramma mostra 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, sono disponibili altre opzioni da considerare:

• 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 nel 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 alzare di livello il server indipendente e rimuoverlo dalla replica.

Gestione della configurazione

Le repliche in lettura vengono considerate server separati in termini di configurazioni del piano di controllo. Questo approccio offre flessibilità per gli scenari di scalabilità in lettura. Tuttavia, quando si usano repliche a scopo di ripristino di emergenza, gli utenti devono 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 PgBouncer è stato abilitato nel database primario ma non nella replica, rimarrà disabilitato nella replica dopo l'innalzamento di livello. Se si desidera avere PgBouncer nel server appena alzato di livello, è necessario abilitarlo prima o dopo l'azione di innalzamento.
• Archivio di backup con ridondanza geografica: le impostazioni di backup geografico non vengono trasferite. Poiché le repliche non possono avere il backup geografico abilitato, il database primario alzato di livello (in precedenza la replica) non lo ha dopo l'innalzamento di livello. La funzionalità può essere attivata solo in fase di creazione del server standard (non in una replica).
• Parametri del server: se i valori differiscono per la replica primaria e di lettura, non cambieranno durante l'innalzamento di livello. È essenziale notare che i parametri che influenzano le dimensioni della memoria condivisa devono avere gli stessi valori sia per il server primario che per le repliche. Questo requisito è dettagliato nella sezione Parametri del server.
• Autenticazione di Microsoft Entra: se il server primario aveva configurato l'autenticazione di Microsoft Entra, ma la replica è stata configurata con l'autenticazione PostgreSQL, dopo l'innalzamento di livello la replica non passerà automaticamente all'autenticazione di Microsoft Entra. Mantiene l'autenticazione PostgreSQL. Gli utenti devono configurare manualmente l'autenticazione di Microsoft Entra nella replica alzata di livello prima o dopo tale processo.
• Disponibilità elevata :se è necessario [HA]/azure/reliability/reliability-postgresql-flexible-server dopo l'innalzamento di livello, è necessario configurarlo nel server primario appena alzato di livello, in seguito all'inversione del ruolo.

Considerazioni

Stati del server durante l'innalzamento di livello

In entrambi gli scenari di innalzamento di livello pianificato e forzato, è necessario che i server (sia primari che di replica) siano in uno stato "Disponibile". Se lo stato di un server è diverso da "Disponibile", ad esempio "Aggiornamento" o "Riavvio", in genere l'innalzamento di livello 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, il metodo di innalzamento di livello forzato può essere implementato 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.

Se il server primario precedente ha esito negativo oltre il ripristino durante la promozione della replica, l'unica opzione consiste nell'eliminare il server primario precedente e ricreare il server di replica.

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

Quando si gestiscono più repliche e se l'area primaria non dispone di un'area associata, è necessario prestare particolare attenzione. Se si verifica un'interruzione a livello di area che interessa il database primario, tutte le altre repliche non vengono riconosciute automaticamente dalla replica appena promossa. Anche se le applicazioni possono ancora essere indirizzate alla replica alzata di livello per un'operazione continua, le repliche non riconosciute rimangono disconnesse durante l'interruzione. Queste repliche aggiuntive riassoceranno e riprenderanno i propri ruoli solo dopo il ripristino dell'area primaria originale.

Ripristino temporizzato durante la promozione

In entrambi gli scenari di promozione pianificata e forzata, è necessario che i backup automatizzati più recenti siano disponibili per garantire che le operazioni PITR siano riuscite. Si è a conoscenza di un problema per cui l'operazione PITR può riscontrare l'errore seguente dopo le operazioni di failover e failback. Questo problema è pianificato per essere risolto in una versione futura. Per garantire il completamento delle operazioni pitr riuscite all'ultima volta, è possibile attendere il completamento del backup automatico dopo un'operazione di innalzamento di livello.

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 si dispone di un server primario abilitato per la disponibilità elevata e di una replica in lettura e si alza di livello la replica per poi tornare al server primario originale, il server sarà ancora a disponibilità elevata?

  No, la disponibilità elevata viene disabilitata durante l'innalzamento di livello iniziale perché non sono supportate repliche in lettura abilitate per la disponibilità elevata. Alzare di livello una replica in lettura in un server primario significa che il server primario originale sta cambiando il ruolo in una replica. Se si torna indietro, è necessario abilitare la disponibilità elevata nel server primario originale.

Contenuto correlato

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