Repliche in lettura nel server singolo di Database di Azure per PostgreSQL

  • Articolo

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

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

La funzionalità relativa alle repliche in lettura consente di replicare i dati dal server del Database di Azure per PostgreSQL ad un server di sola lettura. Le repliche vengono aggiornate in modo asincrono con la tecnologia di replica fisica nativa del motore PostgreSQL. È possibile eseguire la replica dal server primario fino a cinque repliche.

Le repliche sono nuovi server gestiti in modo simile ai normali server di Database di Azure per PostgreSQL. Per ogni replica in lettura, viene addebitato il costo delle risorse di calcolo e di archiviazione sottoposte a provisioning, espresse rispettivamente in vCore e GB/mese.

Informazioni su come creare e gestire le repliche.

Quando usare una replica in lettura

La funzionalità di replica in lettura aiuta a migliorare prestazioni e scalabilità dei carichi di lavoro con utilizzo elevato della lettura. I carichi di lavoro di lettura possono essere isolati alle repliche, mentre i carichi di lavoro di scrittura possono essere indirizzati al primario. Le repliche in lettura possono anche essere distribuite in un'area diversa e possono essere alzate di livello come server di lettura/scrittura in caso di ripristino di emergenza.

Uno scenario comune consiste nel fare in modo che i carichi di lavoro BI e analitici usino le repliche in lettura come origine dati per la creazione di report.

Poiché le repliche sono di sola lettura, non riducono direttamente gli oneri per la capacità di scrittura sul primario.

Considerazioni

La funzionalità è destinata agli scenari in cui il ritardo è accettabile e destinato all'offload delle query. Non è progettato per scenari di replica sincroni in cui i dati della replica devono essere aggiornati. Esisterà un ritardo misurabile significativo tra il primario e la replica. Questo può essere espresso in minuti o anche ore a seconda del carico di lavoro e della latenza tra il database primario e la replica. I dati nella replica diventeranno alla fine coerenti con i dati nel primario. Usare questa funzionalità per i carichi di lavoro in grado di sostenere questo ritardo.

Nota

Per la maggior parte dei carichi di lavoro, le repliche di lettura offrono aggiornamenti quasi in tempo reale dal database primario. Tuttavia, con carichi di lavoro primari persistenti, pesanti e a elevato utilizzo di scrittura, l'intervallo di replica può continuare ad aumentare senza mai raggiungere il database primario. Ciò può anche aumentare l'utilizzo dell'archiviazione nel database primario, perché i file WAL non vengono eliminati fino a quando non vengono ricevuti dalla replica. Se questa situazione è permanente, è possibile eliminare e ricreare la replica in lettura dopo il completamento dei carichi di lavoro a elevato utilizzo di scrittura, per riportare la replica a uno stato valido rispetto al ritardo. Le repliche in lettura asincrone non sono adatte per carichi di lavoro a elevato utilizzo di scrittura. Quando si valutano le repliche in lettura per l'applicazione, monitorare il ritardo nella replica per un ciclo di carico di lavoro completo dell'app attraverso il picco e i periodi non di punta per accedere al possibile ritardo e all'obiettivo RTO/RPO previsto in vari punti del ciclo del carico di lavoro.

Nota

I backup automatici vengono eseguiti per i server di replica configurati con una configurazione di archiviazione fino a 4 TB.

Replica tra più aree

È possibile creare una replica in lettura in un'area diversa dal server primario. La replica tra più aree può essere utile per scenari come la pianificazione del ripristino di emergenza o per avvicinare i dati agli utenti.

Nota

I server di livello Basic supportano solo la replica della stessa area.

È possibile avere un server primario in qualsiasi area di Database di Azure per PostgreSQL. Un server primario può avere una replica nell'area abbinata o nelle aree di replica universale. L'immagine seguente mostra le aree di replica disponibili a seconda dell'area primaria.

Leggere le aree di replica

Aree di replica universali

È sempre possibile creare una replica di lettura in una delle aree seguenti, indipendentemente dalla posizione del server primario. Queste sono le aree di replica universale:

Australia orientale, Australia sud-orientale, Brasile meridionale, Canada centrale, Canada orientale, Stati Uniti centrali, Asia orientale, Stati Uniti orientali, Stati Uniti orientali 2, Giappone orientale, Giappone occidentale, Corea centrale, Corea meridionale, Stati Uniti centro-settentrionali, Europa settentrionale, Stati Uniti centro-meridionali, Asia sud-orientale, Regno Unito meridionale, Regno Unito occidentale, Europa occidentale, Stati Uniti occidentali, Stati Uniti occidentali 2, Stati Uniti centro-occidentali.

Aree abbinate

Oltre alle aree di replica universale, è possibile creare una replica di lettura nell'area abbinata di Azure del server primario. Se non si conosce la coppia di aree di appartenenza, vedere l'articolo Aree associate di Azure per altre informazioni.

Se si usano repliche tra più aree per la pianificazione del ripristino di emergenza, è consigliabile creare la replica nell'area associata anziché in una delle altre aree. Le aree associate evitano aggiornamenti simultanei e assegnano priorità all'isolamento fisico e alla residenza dei dati.

Esistono limitazioni da considerare:

  • Coppie uni direzionali: alcune aree di Azure vengono abbinate in una sola direzione. Queste aree includono India occidentale, Brasile meridionale. Ciò significa che un server primario in India occidentale può creare una replica in India meridionale. Tuttavia, un server primario in India meridionale non può creare una replica in India occidentale. Questo si verifica perché l'area secondaria dell'India occidentale è l'India meridionale, mentre l'area secondaria dell'India meridionale non è l'India occidentale.

Creare una replica

Quando si avvia il flusso di lavoro per la creazione della replica, viene creato un server di Database di Azure per PostgreSQL vuoto. Il nuovo server viene riempito con i dati presenti nel server primario. Il tempo necessario per la creazione dipende dalla quantità di dati nel primario e dal tempo trascorso dall'ultimo backup completo settimanale. Il tempo può variare da pochi minuti a diverse ore.

Ogni replica è abilitata per l'aumento automatico dello spazio di archiviazione. La funzionalità di aumento automatico consente alla replica di rimanere al passo con i dati replicati e di evitare un'interruzione nella replica causata da errori di archiviazione insufficiente.

La funzionalità di replica in lettura usa la replica fisica di PostgreSQL e non la replica logica. Lo streaming della replica usando gli slot di replica è la modalità operativa predefinita. Se necessario, viene usato il log shipping per mettersi in pari.

Informazioni su come creare una replica di lettura nel portale di Azure.

Se il server PostgreSQL di origine è crittografato con chiavi gestite dal cliente, vedere la documentazione per altre considerazioni.

Connessione a una replica

Quando si crea una replica, non eredita le regole del firewall o l'endpoint servizio della rete virtuale del server primario. Queste regole devono essere configurate in modo indipendente per la replica.

La replica eredita l'account amministratore dal server primario. Tutti gli account utente nel server primario vengono replicati nelle repliche di lettura. È possibile connettersi a una replica in lettura solo tramite gli account utente che sono disponibili nel server primario.

È possibile connettersi alla replica usando il relativo nome host e un account utente valido, come si farebbe per un normale server di Database di Azure per PostgreSQL. Per un server denominato replica con il nome utente amministratore myadmin, è possibile connettersi alla replica usando psql:

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

Quando richiesto, immettere la password per l'account dell'utente.

Monitorare la replica

Database di Azure per PostgreSQL fornisce due metriche per il monitoraggio della replica. Le due metriche sono Max Lag Across Replicas (Ritardo massimo tra repliche ) e Replica Lag (Ritardo replica). Per informazioni su come visualizzare queste metriche, vedere la sezione Monitorare una replica dell'articolo Procedura di lettura della replica.

La metrica Max Lag Across Replicas (Ritardo massimo tra repliche ) mostra il ritardo in byte tra la replica primaria e la replica più in ritardo. Questa metrica è applicabile e disponibile solo nel server primario e sarà disponibile solo se almeno una delle repliche in lettura è connessa al server primario e la replica primaria è in modalità di replica di streaming. Le informazioni sul ritardo non mostrano i dettagli quando la replica è in fase di recupero con il database primario usando i log archiviati del database primario in modalità di replica di file shipping.

La metrica Ritardo replica mostra l'ora dall'ultima transazione riprodotta. Se nel server primario non si verificano transazioni, la metrica riflette questo intervallo di tempo. Questa metrica è applicabile e disponibile solo per i server di replica. Il ritardo di replica viene calcolato dalla pg_stat_wal_receiver vista:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

Impostare un avviso per essere informati quando il ritardo di replica raggiunge un valore che non è accettabile per il carico di lavoro.

Per altre informazioni dettagliate, eseguire una query direttamente sul server primario per ottenere il ritardo della replica in byte in tutte le repliche.

Nota

Se un server primario o una replica in lettura viene riavviato, il tempo necessario per il riavvio e il recupero si riflette nella metrica Ritardo replica.

Arrestare la replica/Alzare di livello la replica

È possibile arrestare la replica tra una replica primaria e una replica in qualsiasi momento. L'azione di arresto fa sì che la replica venga riavviata e promuove la replica come server indipendente e scrivibile in lettura autonomo. I dati nel server autonomo sono i dati che erano disponibili nel server di replica al momento dell'arresto della replica. Gli aggiornamenti successivi nel database primario non vengono propagati alla replica. Tuttavia, è possibile che il server di replica abbia accumulato log non ancora applicati. Come parte del processo di riavvio, la replica applica tutti i log in sospeso prima di accettare le connessioni client.

Nota

La reimpostazione della password amministratore nel server di replica non è attualmente supportata. Inoltre, l'aggiornamento della password amministratore insieme all'operazione di promozione della replica nella stessa richiesta non è supportato. Se si vuole eseguire questa operazione, è prima necessario alzare di livello il server di replica, quindi aggiornare la password nel server appena alzato di livello separatamente.

Considerazioni

  • Prima di arrestare la replica in una replica in lettura, verificare la presenza del ritardo di replica per assicurarsi che la replica disponga di tutti i dati necessari.
  • Poiché la replica di lettura deve applicare tutti i log in sospeso prima che possa essere reso un server autonomo, L'RTO può essere superiore per carichi di lavoro con carichi di lavoro di scrittura elevati quando si verifica la replica di arresto perché potrebbe verificarsi un ritardo significativo nella replica. Prestare attenzione a questo problema durante la pianificazione della promozione di una replica.
  • Il server di replica alzato di livello non può essere nuovamente reso in una replica.
  • Se si alza di livello una replica come server primario, non è possibile ripristinare la replica nel server primario precedente. Se si vuole tornare all'area primaria precedente, è possibile stabilire un nuovo server di replica con un nuovo nome (oppure) eliminare il database primario precedente e creare una replica usando il nome primario precedente.
  • Se sono presenti più repliche in lettura e se ne alza di livello una come server primario, gli altri server di replica saranno ancora connessi al server primario precedente. Potrebbe essere necessario ricreare le repliche dal nuovo server alzato di livello.

Quando si arresta la replica, la replica perde tutti i collegamenti alla replica primaria precedente e ad altre repliche.

Informazioni su come arrestare la replica in una replica.

Failover alla replica

In caso di errore del server primario, non viene eseguito automaticamente il failover nella replica di lettura.

Poiché la replica è asincrona, potrebbe verificarsi un notevole ritardo tra la replica primaria e la replica. La quantità di ritardo è influenzata da diversi fattori, ad esempio il tipo di carico di lavoro in esecuzione nel server primario e la latenza tra il server primario e il server di replica. In casi tipici con carico di lavoro di scrittura nominale, il ritardo della replica è previsto tra alcuni secondi e alcuni minuti. Tuttavia, nei casi in cui il carico di lavoro primario viene eseguito con un elevato utilizzo di scrittura e la replica non è abbastanza veloce, il ritardo può essere molto più elevato. È possibile tenere traccia del ritardo di replica per ogni replica usando la metrica Ritardo replica. Questa metrica mostra l'ora dell'ultima transazione riprodotta nella replica. È consigliabile identificare il ritardo medio osservando il ritardo della replica in un periodo di tempo. È possibile impostare un avviso in caso di ritardo della replica, in modo che, se non rientra nell'intervallo previsto, si riceverà una notifica per intervenire.

Suggerimento

Se si esegue il failover nella replica, il ritardo al momento in cui si scollega la replica dal database primario indicherà la quantità di dati persi.

Dopo aver deciso di eseguire il failover in una replica,

  1. Arrestare la replica nella replica
    Questo passaggio è necessario per rendere il server di replica un server autonomo e essere in grado di accettare scritture. Nell'ambito di questo processo, il server di replica verrà riavviato e scollegato dal server primario. Dopo aver avviato la replica, il processo back-end richiede in genere alcuni minuti per applicare eventuali log residui non ancora applicati e per aprire il database come server scrivibile in lettura. Vedere la sezione Arrestare la replica di questo articolo per comprendere le implicazioni di questa azione.

  2. Puntare l'applicazione alla replica (precedente)
    Ogni server ha un stringa di connessione univoco. Aggiornare l'applicazione stringa di connessione in modo che punti alla replica (precedente) anziché alla replica primaria.

Dopo aver elaborato correttamente le letture e le scritture, l'applicazione ha completato il failover. La quantità di tempo di inattività delle esperienze dell'applicazione dipenderà dal momento in cui si rileva un problema e si completano i passaggi 1 e 2 precedenti.

Ripristino di emergenza

Quando si verifica un evento di emergenza importante, ad esempio errori a livello di zona di disponibilità o a livello di area, è possibile eseguire un'operazione di ripristino di emergenza promuovendo la replica in lettura. Dal portale dell'interfaccia utente è possibile passare al server di replica di lettura. Selezionare quindi la scheda replica e arrestare la replica per alzarla di livello come server indipendente. In alternativa, è possibile usare l'interfaccia della riga di comando di Azure per arrestare e alzare di livello il server di replica.

Considerazioni

Questa sezione riepiloga le considerazioni sulla funzionalità di replica in lettura.

Prerequisiti

Le repliche in lettura e la decodifica logica dipendono sia dal log di scrittura in avanti postgres (WAL) per informazioni. Queste due funzionalità richiedono livelli diversi di registrazione da Postgres. La decodifica logica richiede un livello superiore di registrazione rispetto alle repliche in lettura.

Per configurare il livello corretto di registrazione, usare il parametro di supporto della replica di Azure. Il supporto della replica di Azure include tre opzioni di impostazione:

  • Off : inserisce le informazioni meno contenute nel wal. Questa impostazione non è disponibile nella maggior parte dei server Database di Azure per PostgreSQL.
  • Replica : più dettagliato di Off. Si tratta del livello minimo di registrazione necessario per il funzionamento delle repliche in lettura. Questa impostazione è l'impostazione predefinita nella maggior parte dei server.
  • Logico : più dettagliato rispetto a Replica. Si tratta del livello minimo di registrazione per il funzionamento della decodifica logica. Le repliche di lettura funzionano anche in questa impostazione.

Nuove repliche

Una replica in lettura viene creata come nuovo server di Database di Azure per PostgreSQL. Un server esistente non può essere impostato come replica. Non è possibile creare una replica di un'altra replica in lettura.

Configurazione della replica

Una replica viene creata usando le stesse impostazioni di calcolo e archiviazione del database primario. Dopo aver creato una replica, è possibile modificare diverse impostazioni, tra cui l'archiviazione e il periodo di conservazione dei backup.

Le regole del firewall, le regole di rete virtuale e le impostazioni dei parametri non vengono ereditate dal server primario alla replica quando la replica viene creata o successivamente.

Scalabilità

Ridimensionamento di vCore o tra utilizzo generico e ottimizzato per la memoria:

  • PostgreSQL richiede che l'impostazione max_connections in un server secondario sia maggiore o uguale all'impostazione nel database primario. In caso contrario, il database secondario non verrà avviato.
  • In Database di Azure per PostgreSQL, le connessioni massime consentite per ogni server sono fisse allo SKU di calcolo poiché le connessioni occupano memoria. Altre informazioni sul mapping tra max_connections e SKU di calcolo.
  • Aumento delle prestazioni: aumentare prima le prestazioni di calcolo di una replica, quindi aumentare le prestazioni del database primario. Questo ordine impedirà agli errori di violare il max_connections requisito.
  • Riduzione delle prestazioni: ridurre prima le prestazioni di calcolo del database primario, quindi ridurre le prestazioni della replica. Se si tenta di ridimensionare la replica inferiore a quella primaria, si verifica un errore perché questo viola il max_connections requisito.

Ridimensionamento dell'archiviazione:

  • Tutte le repliche hanno l'aumento automatico delle risorse di archiviazione per impedire problemi di replica da una replica completa dell'archiviazione. Questa impostazione non può essere disabilitata.
  • È anche possibile aumentare manualmente l'archiviazione, come si farebbe in qualsiasi altro server

Livello Basic

I server di livello Basic supportano solo la replica della stessa area.

max_prepared_transactions

PostgreSQL richiede che il valore del max_prepared_transactions parametro nella replica di lettura sia maggiore o uguale al valore primario. In caso contrario, la replica non verrà avviata. Se si vuole modificare max_prepared_transactions il database primario, modificarlo prima nelle repliche.

Repliche arrestate

Se si arresta la replica tra un server primario e una replica in lettura, la replica viene riavviata per applicare la modifica. La replica arrestata diventa un server autonomo che supporta sia la lettura che la scrittura. Il server autonomo non può essere di nuovo impostato come replica.

Server primari e autonomi eliminati

Quando un server primario viene eliminato, tutte le repliche in lettura diventano server autonomi. Le repliche vengono riavviate in modo da riflettere questa modifica.

Passaggi successivi