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

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

Importante

Database di Azure per PostgreSQL - Il server singolo è in fase 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 Cosa succede a Database di Azure per PostgreSQL - Server singolo?.

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 in lettura vengono aggiornate in modo asincrono tramite la tecnologia di replica fisica nativa del motore PostgreSQL. È possibile creare fino a un massimo di cinque repliche da un server primario.

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 essere distribuite anche 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 ed è destinata all'offload delle query. Non è progettata per scenari di replica sincrona, in cui i dati di replica devono essere aggiornati. Esisterà un ritardo misurabile significativo tra il primario e la replica. Il ritardo può essere di minuti o anche ore, a seconda del carico di lavoro e della latenza tra primario e 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 l'intervallo di tempo per la replica per un ciclo di carico di lavoro dell'app completo, sia nei tempi di picco che nei tempi non di picco, per accedere al ritardo possibile e agli RTO/RPO previsti in diversi punti del ciclo del carico di lavoro.

Nota

I backup automatici vengono eseguiti per i server di replica configurati con 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. Per un server primario può essere presente una replica nella relativa area associata o nelle aree di replica universali. L'immagine seguente illustra le aree di replica disponibili a seconda dell'area primaria.

Aree di replica universali

È sempre possibile creare una replica in 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 sudorientale, 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 universali, è possibile creare una replica in lettura nell'area associata 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.

È necessario considerare alcune limitazioni:

• Coppie unidirezionali: alcune aree di Azure vengono abbinate in una sola direzione. Queste aree includono India occidentale e Brasile meridionale. Ciò significa che un server primario in India occidentale può creare una replica in India meridionale. Al contrario, 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 adattarsi ai dati replicati e impedire un'interruzione della replica causata da errori di spazio 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, questa non eredita le regole del firewall o l'endpoint del servizio 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 in 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 myreplica 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 offre due metriche per il monitoraggio della replica. Le due metriche sono Ritardo massimo tra repliche e Ritardo replica. Per informazioni su come visualizzare queste metriche, vedere la sezione Monitorare una replica dell'articolo sulla procedura per la replica in lettura.

La metrica Ritardo massimo tra repliche indica il ritardo in byte che intercorre tra il server primario 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 se quest'ultimo è in modalità di replica di streaming. Le informazioni sul ritardo non mostrano i dettagli quando la replica è in fase di recupero con il server primario usando i log archiviati del database primario in modalità di replica di file shipping.

La metrica Ritardo della replica indica il tempo trascorso dall'ultima transazione riprodotta. Se non sono presenti transazioni sul server primario, 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 vista pg_stat_wal_receiver:

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 di replica in byte per tutte le repliche.

Nota

In caso di riavvio di un server primario o di una replica in lettura, il tempo necessario per il riavvio e per mettersi in pari sarà indicato nella metrica Replica Lag (Ritardo della 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 alza il livello della replica a server indipendente, autonomo e leggibile-scrivibile. 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 separatamente la password nel server appena alzato di livello.

Considerazioni

• Prima di arrestare la replica in una replica in lettura, controllare il ritardo di replica per assicurarsi che la replica abbia tutti i dati necessari.
• Poiché la replica di lettura deve applicare tutti i log in sospeso prima di poter essere trasformata in server autonomo, L'RTO può essere superiore per carichi di lavoro di scrittura elevati quando si verifica l'arresto della replica perché potrebbe verificarsi un ritardo significativo correlato. Prestare attenzione a questo problema durante la pianificazione dell'innalzamento di livello di una replica.
• Il server di replica alzato di livello non può essere nuovamente inserito in una replica.
• Se si alza di livello una replica come server primario, non sarà 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, questa 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 il server primario 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 è stimato 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 questo modo, se non rientra nell'intervallo atteso, verrà richiesto di intervenire.

Suggerimento

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

Dopo aver deciso di eseguire il failover in una replica,

1. Arrestare la replica per la replica
   Questo passaggio è necessario per consentire al server di replica di diventare un server autonomo e accettare le 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 una stringa di connessione univoca. Aggiornare la stringa di connessione dell'applicazione in modo che punti alla replica (precedente) anziché alla replica primaria.

Il failover è completato dopo che l'applicazione ha elaborato correttamente le letture e le scritture. 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 indicati in precedenza.

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 di 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 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 di Database di Azure per PostgreSQL.
• Replica : più dettagliato di Off. Si tratta del livello minimo di registrazione necessario per il funzionamento delle repliche di lettura. Questa impostazione è l'impostazione predefinita nella maggior parte dei server.
• Logico: più dettagliato di 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 server 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 della rete virtuali e le impostazioni dei parametri vengono ereditate dal server principale e applicate alla replica quando viene creata o in un secondo momento.

Scalabilità

Ridimensionamento di vCore tra scenari di 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 server primario, altrimenti il database secondario non verrà avviato.
• In Database di Azure per PostgreSQL, le connessioni massime consentite per ogni server sono fisse all'SKU di calcolo poiché le connessioni occupano memoria. Altre informazioni sul mapping tra SKU max_connections e SKU di calcolo.
• Aumento delle prestazioni: aumentare prima le prestazioni di calcolo di una replica, quindi aumentare le prestazioni del server primario. Questo ordine impedirà agli errori di violare il requisito di max_connections.
• Ridimensionamento: ridurre prima le prestazioni di calcolo del database primario, quindi ridurre le prestazioni della replica. Se si tenta di ridimensionare la replica a un livello inferiore di quello primario, si verifica un errore perché l'operazione viola il requisito max_connections.

Ridimensionamento dello spazio di archiviazione:

• Tutte le repliche hanno l'aumento automatico delle risorse di archiviazione abilitato 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 parametro max_prepared_transactions sulla replica in lettura sia maggiore o uguale a quello del primario; in caso contrario, la replica non si avvia. Per modificare max_prepared_transactions nel server primario, modificarlo prima di tutto nelle repliche.

Repliche arrestate

Se si arresta la replica tra un server primario e una replica in lettura, la replica verrà riavviata per poter applicare tale 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 viene eliminato un server primario, tutte le relative repliche in lettura diventano server autonomi. Le repliche vengono riavviate in modo da riflettere questa modifica.

Passaggi successivi

• Informazioni su come creare e gestire le repliche in lettura nel portale di Azure.
• Informazioni su come creare e gestire le repliche in lettura con l'interfaccia della riga di comando di Azure e l'API REST