Repliche in lettura in Database di Azure per PostgreSQL - Server flessibile

La funzionalità di replica in lettura consente di replicare i dati da un server flessibile Database di Azure per PostgreSQL a una replica di sola lettura. Le repliche vengono aggiornate in modo asincrono usando la tecnologia di replica fisica nativa del motore PostgreSQL. Lo streaming della replica usando gli slot di replica è la modalità operativa predefinita. Quando necessario, il log shipping basato su file viene usato per recuperare. È possibile eseguire la replica dal server primario fino a cinque repliche.

Le repliche sono nuovi server che gestisci in modo simile ai normali server Database di Azure per PostgreSQL Flexible Server. Per ogni replica in lettura, si paga per le risorse di calcolo provisionate in vCore e per lo spazio di archiviazione in GB al mese.

Scopri come creare una replica in lettura.

Quando usare una replica in lettura

La funzionalità di replica di lettura contribuisce a migliorare le prestazioni e la scalabilità dei carichi di lavoro a elevata intensità di lettura. È possibile isolare i carichi di lavoro di lettura nelle repliche, mentre si indirizzano i carichi di lavoro di scrittura al database primario. È anche possibile distribuire repliche di lettura in un'altra regione e promuoverle a server di lettura-scrittura in caso di necessità 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

Le repliche in lettura sono progettate principalmente per scenari in cui l'offload delle query è utile e un lieve ritardo è gestibile. Sono ottimizzati per fornire aggiornamenti quasi in tempo reale dal database primario per la maggior parte dei carichi di lavoro, rendendoli una soluzione eccellente per gli scenari con un numero elevato di operazioni di lettura. Tuttavia, è importante notare che non sono destinate a scenari di replica sincrona che richiedono l'accuratezza dei dati fino al minuto. Anche se i dati nella replica diventano coerenti con il database primario, potrebbe verificarsi un ritardo, che in genere varia da pochi secondi a minuti e in alcuni scenari di carico di lavoro o di latenza elevata, questo ritardo potrebbe estendersi a ore. In genere, le repliche in lettura nella stessa area del database primario hanno meno ritardo rispetto alle repliche geografiche, poiché quest'ultima spesso si occupa della latenza indotta dalla distanza geografica. Per altre informazioni sulle implicazioni sulle prestazioni della replica geografica, vedere l'articolo Replica geografica. 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.

Annotazioni

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 a elevato utilizzo di scrittura persistente, il ritardo di replica può continuare a crescere e potrebbe essere in grado di raggiungere solo il database primario. Questa situazione potrebbe anche aumentare l'utilizzo dello spazio di archiviazione sul nodo primario, poiché i file WAL vengono eliminati solo una volta ricevuti dalla replica. Se questa situazione persiste, eliminare e ricreare la replica di lettura una volta completati i carichi di lavoro a elevata intensità di scrittura riporta la replica a uno stato in cui il ritardo è contenuto. Le repliche di lettura asincrone non sono adatte a carichi di scrittura così elevati. 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.

Creare una replica

È possibile distribuire un server primario per Database di Azure per PostgreSQL server flessibile in qualsiasi area che supporta il servizio. È possibile creare repliche del server primario all'interno della stessa area o in aree Azure globali diverse in cui è disponibile Database di Azure per PostgreSQL. È anche possibile creare repliche in alcune aree Azure nei cloud sovrani. Per un elenco delle aree cloud sovrane in cui è possibile creare repliche, vedere l'articolo Replica geografica .

Quando si avvia il flusso di lavoro di creazione della replica, il processo crea un server flessibile Database di Azure per PostgreSQL vuoto. Il nuovo server viene riempito con i dati nel server primario. Per creare repliche nella stessa regione, il processo utilizza un approccio basato su snapshot. Di conseguenza, il tempo di creazione è indipendente dalle dimensioni dei dati. Le repliche geografiche vengono create usando il backup di base del database primario, che viene quindi trasmesso in rete. Pertanto, il tempo di creazione potrebbe variare da minuti a diverse ore, a seconda delle dimensioni primarie.

Una replica viene considerata creata correttamente solo quando vengono soddisfatte due condizioni: l'intero backup del database primario viene copiato nella replica e i log delle transazioni vengono sincronizzati senza più di un ritardo di 1 GB.

Per ottenere un'operazione di creazione riuscita, evitare di eseguire repliche durante i periodi di caricamento transazionale elevato. Ad esempio, evita di creare repliche durante la migrazione da altre origini dati a un server flessibile di Database di Azure per PostgreSQL o durante operazioni di caricamento in blocco di grandi dimensioni. Se si esegue la migrazione dei dati o si caricano grandi quantità di dati, completare prima questa attività. Al termine, è possibile avviare la configurazione delle repliche. Una volta completata l'operazione di migrazione o di caricamento in blocco, verificare se la dimensione del log delle transazioni sia tornata alle dimensioni normali. In genere, le dimensioni del log delle transazioni devono essere vicine al valore definito nel parametro per il max_wal_size server. È possibile monitorare lo spazio di archiviazione occupato dal log delle transazioni utilizzando la metrica Transaction Log Storage Used, che fornisce informazioni sulla quantità di spazio di archiviazione usata dal log delle transazioni. Monitorando questa metrica, è possibile assicurarsi che le dimensioni del log delle transazioni siano entro l'intervallo previsto e che il processo di creazione della replica possa essere avviato.

Importante

Le repliche in lettura sono attualmente supportate per i livelli di calcolo server per utilizzo generico e ottimizzato per la memoria. Il livello di calcolo del server con burst non è supportato.

Importante

Quando si eseguono operazioni di creazione, eliminazione e promozione della replica, il server primario entra in uno stato di aggiornamento. Durante questo periodo di tempo, le operazioni di gestione del server, ad esempio la modifica dei parametri, la modifica delle opzioni di disponibilità elevata o l'aggiunta o la rimozione di firewall non sono disponibili. Lo stato di aggiornamento influisce solo sulle operazioni di gestione del server e non influisce sulle operazioni del piano dati . Questa condizione significa che il server di database rimane completamente funzionante e in grado di accettare connessioni, nonché di gestire il traffico di lettura e scrittura.

Scopri come Creare una replica in lettura.

Gestione della configurazione

Quando si configurano repliche in lettura per un server flessibile Database di Azure per PostgreSQL, è necessario comprendere quali configurazioni del server è possibile modificare, quali configurazioni ereditano dalla replica dal server primario e eventuali limitazioni correlate.

Configurazioni ereditate

Quando si crea una replica di lettura, eredita configurazioni server specifiche dal server primario. È possibile modificare queste configurazioni durante la creazione della replica o dopo aver configurato la replica. Tuttavia, la replica di lettura non eredita impostazioni specifiche, ad esempio il backup geografico, dal server primario.

Configurazioni durante la creazione della replica

  • Livello, dimensioni di archiviazione: per l'operazione alzata di livello al server primario , le dimensioni di livello e archiviazione devono corrispondere al server primario. Per l'operazione promuovi a server indipendente e rimuovi dalla replica, il livello e le dimensioni di archiviazione possono essere uguali o superiori a quelli del server primario.
  • Livello di prestazioni (operazioni di I/O al secondo): regolabile.
  • Crittografia dei dati: regolabile, incluso il passaggio da chiavi gestite dal servizio alle chiavi gestite dal cliente.

Configurazioni dopo la creazione

  • Regole del firewall: è possibile aggiungere, eliminare o modificare regole.
  • Livello, dimensioni di archiviazione: per l'operazione alzata di livello al server primario , le dimensioni di livello e archiviazione devono corrispondere al server primario. Per l'operazione di passaggio a server indipendente e rimozione dalla replica, il livello e le dimensioni di archiviazione possono essere uguali o superiori a quelli del server primario.
  • Livello di prestazioni (operazioni di I/O al secondo): regolabile.
  • metodo Autenticazione: regolabile, le opzioni includono il passaggio dall'autenticazione PostgreSQL alla Microsoft Entra.
  • Parametri: la maggior parte dei parametri è regolabile. Tuttavia, quelli che influiscono sulle dimensioni della memoria condivisa devono essere allineati al server primario, soprattutto per potenziali scenari di promozione ai server primari . Per promuovere il server indipendente e rimuoverlo dall'operazione di replica , questi parametri devono corrispondere o superare quelli nel server primario.
  • Pianificazione della manutenzione: regolabile.

Funzionalità non supportate nelle repliche in lettura

I server primari supportano alcune funzionalità che non è possibile configurare sulle repliche di lettura. Queste funzionalità includono:

  • Backup, inclusi i backup geografici.
  • Disponibilità elevata (HA).

Se il server flessibile di origine di Database di Azure per PostgreSQL è crittografato con chiavi gestite dal cliente, consulta la documentazione per ulteriori considerazioni.

Creare repliche di lettura a cascata

Le repliche in lettura a catena consentono di distribuire i carichi di lavoro di lettura, riducendo il carico nel server primario. La distribuzione di repliche di lettura in regioni diverse (repliche di lettura tra regioni) consente di distribuire il traffico di lettura più vicino agli utenti nei vari luoghi. È possibile aggiungere repliche di lettura in cascata al server Database di Azure per PostgreSQL. Questa funzionalità consente di creare nuove repliche di lettura a partire da una replica di lettura esistente, che funge da origine per il livello successivo.

La replica di lettura di primo livello replica in modo asincrono i dati dal server primario. È quindi possibile creare una replica di lettura di secondo livello usando la replica di primo livello come origine, formando una gerarchia di replica a due livelli. Questa architettura aumenta la scalabilità, supportando fino a 30 server di replica di lettura: il server primario può supportare fino a cinque repliche di lettura e ciascuna di queste può supportare altre cinque repliche. Per aggiungere una replica in lettura a catena a Database di Azure per PostgreSQL server flessibile, selezionare la replica di lettura esistente (creata dal server primario), passare alla scheda Replica e selezionare Crea replica.

Ad esempio, il server primario può avere fino a cinque repliche di lettura (livello 1). Uno di questi, ad esempio read-replica-1, funge da origine per un'altra replica read-replica-2 che diventa parte di (livello 2).

Considerazioni principali

  • È possibile creare fino a cinque repliche di lettura per ogni replica di lettura di origine, con supporto per due livelli di replica.
  • L'operazione di switchover supporta la replica di lettura intermedia (origine) e la replica di lettura a cascata.
  • L'operazione di promozione alla replica primaria non supporta repliche di lettura intermedie con repliche in lettura a catena.
  • Gli endpoint virtuali non sono supportati per le repliche a catena.
  • Le repliche in lettura a catena sono supportate nelle repliche intermedie con PostgreSQL versione 14 e successive.

Connessione a una replica

Quando si crea una replica, non eredita le regole del firewall o l'endpoint servizio di rete virtuale del server primario. È possibile impostare queste regole durante la creazione della replica e modificarle in un secondo momento.

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 di lettura solo usando gli account utente disponibili nel server primario.

È possibile usare due metodi per connettersi alla replica:

  • Diretto alla replica: è possibile connettersi alla replica usando il nome host e un account utente valido, proprio come in un normale server flessibile 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 postgres

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

Per semplificare il processo di connessione, il portale di Azure fornisce stringhe di connessione pronte all'uso. Queste stringhe di connessione sono disponibili nella pagina Connetti . Includono sia libpq variabili sia stringhe di connessione adattate alle console bash.

  • Mediante endpoint virtuali: un metodo di connessione alternativo si basa su endpoint virtuali. Per altre informazioni, vedere Endpoint virtuali. Usando gli endpoint virtuali, è possibile configurare l'endpoint di sola lettura in modo che punti sempre alla replica, indipendentemente dal server attualmente in possesso del ruolo di replica.

Monitorare la replica

La funzionalità di replica in lettura in Database di Azure per PostgreSQL si basa sul meccanismo degli slot di replica. Il vantaggio principale degli slot di replica è che regolano automaticamente il numero di log delle transazioni (segmenti WAL) richiesti da tutti i server di replica. Questa regolazione consente di evitare che le repliche non vengano sincronizzate perché evita l'eliminazione di segmenti WAL nel database primario prima che le repliche li ricevano. Lo svantaggio di questo approccio è il rischio di esaurire spazio nel database primario se lo slot di replica rimane inattivo per un periodo di tempo prolungato. In tali situazioni, il database primario accumula i file WAL, causando una crescita incrementale dell'utilizzo dello spazio di archiviazione. Quando l'utilizzo dell'archiviazione raggiunge 95% o se la capacità disponibile è inferiore a 5 GiB, il server passa automaticamente alla modalità di sola lettura per evitare errori associati a situazioni complete del disco.
Di conseguenza, il monitoraggio dello stato degli slot di replica e ritardo della replica è fondamentale per le repliche in lettura.

Impostare le regole di avviso per l'archiviazione usata o la percentuale di archiviazione e per i ritardi di replica, quando superano determinate soglie in modo da poter agire in modo proattivo, aumentare le dimensioni di archiviazione ed eliminare repliche di lettura in ritardo. Ad esempio, è possibile impostare un avviso se la percentuale di archiviazione supera l'80% di utilizzo e se il ritardo della replica è superiore a 5 minuti. La metrica Transaction Log Storage Used indica se l'accumulo dei file WAL è il motivo principale dell'utilizzo eccessivo dello spazio di archiviazione.

Monitoraggio delle metriche

Database di Azure per PostgreSQL servizio fornisce le metriche seguenti per il monitoraggio della replica.

È possibile usare metriche avanzate per il monitoraggio e l'invio di avvisi relativi alla replica in lettura.

Abilitazione delle metriche avanzate

  • La maggior parte di queste nuove metriche è disabilitata per impostazione predefinita. Esistono tuttavia alcune eccezioni, che sono abilitate per impostazione predefinita. La colonna più a destra delle tabelle seguenti indica se ogni metrica è abilitata o meno per impostazione predefinita.
  • Per abilitare le metriche che non sono abilitate per impostazione predefinita, impostare il parametro metrics.collector_database_activity su ON. Questo parametro è dinamico e non richiede un riavvio dell'istanza.
Replica logica
Nome visualizzato ID metrica Unità Description Dimensione Impostazione predefinita abilitata
Ritardo massimo di replicazione logica logical_replication_delay_in_bytes Bytes Ritardo massimo su tutti gli slot di replica logica. Non applicabile Yes
Duplicazione
Nome visualizzato ID metrica Unità Description Dimensione Impostazione predefinita abilitata
Ritardo massimo nella replica fisica physical_replication_delay_in_bytes Bytes Ritardo massimo su tutti gli slot di replica fisica asincroni. Non applicabile Yes
Ritardo replica in lettura physical_replication_delay_in_seconds Secondi Ritardo della replica in lettura in secondi. Non applicabile Yes

Per ulteriori informazioni, vedere l'articolo guida sulla replica in lettura.

La metrica Max Physical Replication Lag mostra il ritardo in byte tra la replica primaria e la replica più in ritardo. Questa metrica è applicabile e disponibile solo nel server primario ed è disponibile solo se almeno una delle repliche in lettura è connessa al server primario. Le informazioni sul ritardo sono presenti anche quando la replica è in fase di recupero con la replica primaria, durante la creazione della replica o quando la replica diventa inattiva.

La metrica Read Replica Lag indica il tempo trascorso dall'ultima transazione riprodotta. Ad esempio, se non si verificano transazioni nel server primario e l'ultima transazione è stata riprodotta 5 secondi fa, il ritardo di replica di lettura mostra un ritardo di 5 secondi. Questa metrica è applicabile e disponibile solo nelle repliche.

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 tutte le repliche.

Annotazioni

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).

Stato della replica

Per monitorare il progresso e lo stato della replica e gestire l'operazione, vedere la colonna Replication state nel portale di Azure. Questa colonna si trova nella pagina di replica e visualizza vari stati che forniscono informazioni dettagliate sulla condizione corrente delle repliche di lettura e il relativo collegamento al database primario. Per gli utenti che si basano sull'API di Azure Resource Manager, quando si richiama l'API GetReplica, lo stato viene visualizzato come ReplicationState nel contenitore delle proprietà replica.

Ecco i valori possibili:

Stato della replica Descrizione Ordine Alza di livello Ordine di creazione delle repliche in lettura
Riconfigurazione In attesa dell'inizio del collegamento replica primario. Potrebbe rimanere più lungo se la replica o la relativa area non è disponibile, ad esempio a causa di un'emergenza. 1 N/A
Provisioning È in corso il provisioning della replica in lettura e la replicazione tra i due server non è ancora iniziata. Fino al completamento del provisioning, non è possibile connettersi alla replica di lettura. N/A 1
Aggiornamento La configurazione del server è in fase di preparazione dopo un'azione attivata, ad esempio la promozione o la creazione di repliche in lettura. 2 2
Recupero I file WAL vengono applicati alla replica. La durata di questa fase durante l'innalzamento di livello dipende dall'opzione di sincronizzazione dati scelta, pianificata o forzata. 3 3
Attivo Stato integro, che indica che la replica di lettura è connessa correttamente al database primario. Se i server vengono arrestati ma sono stati connessi correttamente prima, lo stato rimane attivo. 4 4
Interrotto Stato non integro, che indica che l'operazione di promozione potrebbe avere avuto esito negativo o che la replica non è in grado di connettersi al database primario per qualche motivo. Per risolvere questo stato, eliminare la replica e ricreare la replica. N/A N/A

Informazioni su come monitorare la replica.

Considerazioni

Questa sezione riepiloga le considerazioni sulla funzionalità di lettura replica. Si applicano le considerazioni seguenti.

  • Operazioni di risparmio energia: è possibile applicare le operazioni di risparmio energia, incluse le azioni di avvio e arresto , sia ai server primario che a quello di replica. Tuttavia, per mantenere l'integrità del sistema, seguire una sequenza specifica. Prima di arrestare le repliche di lettura, verificare che il server primario venga arrestato per primo. Quando si iniziano le operazioni, avviare l'azione di avvio nei server di replica prima di avviare il server primario.
  • Se un server ha repliche di lettura, eliminare prima le repliche di lettura e poi il server primario.
  • L'aggiornamento sul posto della versione principale per un server flessibile di Database di Azure per PostgreSQL richiede la rimozione di eventuali repliche di lettura e repliche di lettura a cascata abilitate sul server. Dopo l'eliminazione delle repliche, è possibile aggiornare il server primario alla versione principale desiderata. Al termine dell'aggiornamento, è possibile ricreare le repliche per riprendere il processo di replica.
    • Reimpostazione della password amministratore: la reimpostazione della password amministratore nel server di replica non è attualmente supportata. Inoltre, l'aggiornamento della password dell'amministratore insieme alla promozione dell'operazione di replica nella stessa richiesta non è supportata. Se si desidera eseguire queste azioni, alzare di livello prima il server di replica e quindi aggiornare la password nel server appena alzato di livello separatamente.

Nuove repliche

È possibile creare una replica di lettura come un nuovo server flessibile di Database di Azure per PostgreSQL. Non è possibile creare un server esistente in una replica.

Spostamento delle risorse

È possibile creare repliche di lettura in un gruppo di risorse diverso da quello primario. Tuttavia, il trasferimento delle repliche in lettura in un altro gruppo di risorse dopo la creazione non è supportato. Inoltre, lo spostamento delle repliche in una sottoscrizione diversa non è supportato. Lo spostamento del database primario con repliche in lettura in un altro gruppo di risorse o sottoscrizione non è supportato.

Aumento automatico dell'archiviazione

Quando si configurano repliche di lettura per un server flessibile Database di Azure per PostgreSQL, assicurarsi che l'impostazione di aumento automatico delle risorse di archiviazione nelle repliche corrisponda a quella del server primario. La funzionalità di aumento automatico dell'archiviazione consente all'archiviazione del database di aumentare automaticamente per evitare l'esaurimento dello spazio, che potrebbe causare interruzioni del database. Ecco come gestire le impostazioni di aumento automatico dell'archiviazione in modo efficace:

  • È possibile abilitare l'aumento automatico delle risorse di archiviazione in qualsiasi replica indipendentemente dall'impostazione del server primario.
  • Se l'aumento automatico dell'archiviazione è abilitato nel server primario, deve essere abilitato anche nelle repliche per garantire la coerenza nei comportamenti di ridimensionamento dell'archiviazione.
  • Per abilitare l'aumento automatico dell'archiviazione nel database primario, è prima necessario abilitarlo nelle repliche. Questo ordine di operazioni è fondamentale per mantenere l'integrità della replica.
  • Viceversa, se si vuole disabilitare l'aumento automatico dell'archiviazione, iniziare disabilitandolo nel server primario prima delle repliche per evitare complicazioni di replica.

Backup e ripristino

Quando si gestiscono backup e ripristini per il server flessibile Database di Azure per PostgreSQL, tenere presente il ruolo corrente e precedente del server in diversi scenari di promozione. Tenere presente questi punti chiave:

Alzare di livello al server primario

  • Nessun backup da repliche di lettura: il sistema non esegue mai backup dai server di replica di lettura, indipendentemente dal loro ruolo precedente.
  • Conservazione dei backup precedenti: se un server era una volta un server primario e il sistema ha eseguito i backup durante tale periodo, mantiene tali backup fino al periodo di conservazione definito dall'utente.
  • Restrizioni relative alle operazioni di ripristino: anche se esistono backup passati per un server che esegue la transizione a una replica in lettura, le operazioni di ripristino sono limitate. È possibile avviare un'operazione di ripristino solo quando il server viene alzato di livello al ruolo primario.

Per maggiore chiarezza, la tabella seguente illustra questi punti:

Ruolo del server Backup eseguito Ripristino consentito
Primary Yes Yes
Replica in lettura NO NO
Replica in lettura promossa a primaria Yes Yes

Alzare di livello a un server indipendente e rimuovere dalla replica

Finché il server è una replica di lettura, il sistema non esegue backup. Tuttavia, dopo averlo alzato di livello a un server indipendente, il sistema esegue backup sia per il server alzato di livello che per il server primario. È possibile ripristinare i backup in entrambi i server.

Rete

Le repliche in lettura supportano tutte le opzioni di rete supportate da Database di Azure per PostgreSQL - Server flessibile.

Importante

La comunicazione bidirezionale tra il server primario e le repliche in lettura è fondamentale per la configurazione Database di Azure per PostgreSQL. La subnet della rete virtuale Azure deve consentire l'invio e la ricezione del traffico sulla porta di destinazione 5432.

Questo requisito non solo facilita il processo di sincronizzazione, ma garantisce anche il corretto funzionamento del meccanismo di promozione. Le repliche potrebbero dover comunicare in ordine inverso, dalla replica alla replica primaria, in particolare durante la promozione alle operazioni primarie. Inoltre, è necessario consentire le connessioni all'account di archiviazione Azure che archivia gli archivi di registrazione Write-Ahead (WAL) per mantenere la durabilità dei dati e consentire processi di ripristino efficienti.

Per altre informazioni su come configurare l'accesso privato (integrazione di rete virtuale) per le repliche in lettura e comprendere le implicazioni per la replica tra aree Azure e reti virtuali all'interno di un contesto di rete privata, vedere l'articolo Replica tra aree Azure e reti virtuali con rete privata.

Mitigazione dei problemi dello slot di replica

In rari casi, un ritardo elevato causato dagli slot di replica può comportare un aumento dell'utilizzo dello spazio di archiviazione nel server primario a causa di file WAL accumulati. Se l'utilizzo dello spazio di archiviazione raggiunge il 95% o la capacità disponibile scende al di sotto di 5 GiB, il server passa automaticamente alla modalità di sola lettura per evitare errori completi del disco.

La gestione dell'integrità e delle funzionalità del server primario è una priorità. In questi casi perimetrali, il server potrebbe eliminare lo slot di replica per garantire che il server primario rimanga operativo per il traffico di lettura e scrittura. Pertanto, la replica passa alla modalità di log shipping basata su file, che potrebbe comportare un ritardo di replica superiore.

Monitora attentamente l'utilizzo dello spazio di archiviazione e la latenza della replica e adotta le misure necessarie per mitigare potenziali problemi prima che si aggravino.

Parameters

Quando si crea una replica di lettura, eredita i parametri dal server primario. Questa ereditarietà garantisce un punto di partenza coerente e affidabile. Tuttavia, tutte le modifiche apportate ai parametri nel server primario apportate dopo la creazione della replica di lettura non vengono replicate automaticamente. Questo comportamento offre il vantaggio dell'ottimizzazione individuale della replica in lettura, ad esempio il miglioramento delle prestazioni per le operazioni a elevato utilizzo di lettura senza modificare i parametri del server primario. Anche se questo comportamento offre flessibilità e opzioni di personalizzazione, richiede anche un'attenta e manuale gestione per mantenere la coerenza tra la replica primaria e la replica quando è necessaria l'uniformità dei parametri.

Gli amministratori possono modificare i parametri nel server di replica di lettura e impostare valori diversi rispetto al server primario. L'unica eccezione è costituita da parametri che potrebbero influire sul ripristino della replica, menzionati anche nella sezione "Ridimensionamento" seguente: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. Per garantire che il ripristino della replica di lettura sia facile e non si verifichino limitazioni di memoria condivisa, impostare sempre questi parametri specifici su valori equivalenti o superiori a quelli configurati nel server primario. Prima di abbassare i valori dei parametri su un server di replica in lettura, assicurarsi che il ritardo di replicazione sia minimo o che la replica sia completamente allineata con il server primario, per evitare potenziali problemi di replicazione o recupero.

Scale

È possibile aumentare e ridurre le prestazioni di calcolo (vCore), modificare il livello di servizio da Utilizzo generico a Ottimizzato per la memoria (o viceversa) e aumentare le prestazioni di archiviazione. Tuttavia, si applicano le avvertenze seguenti.

Per il ridimensionamento delle risorse di calcolo:

  • Il servizio Database di Azure per PostgreSQL richiede che diversi parametri nelle repliche siano maggiori o uguali all'impostazione sul server primario per assicurarsi che la replica non esaurisca la memoria condivisa durante il ripristino. I parametri interessati sono: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

  • Aumento delle prestazioni: aumentare prima le prestazioni di calcolo di una replica, quindi aumentare le prestazioni del server primario.

  • Ridimensionamento: ridurre prima le prestazioni di calcolo del database primario, quindi ridurre le prestazioni della replica.

  • La capacità di calcolo nel nodo primario deve essere sempre uguale o inferiore a quella della replica con minore capacità di calcolo.

Per il ridimensionamento dell'archiviazione:

  • Aumento delle prestazioni: aumentare prima le prestazioni di archiviazione di una replica, quindi aumentare le prestazioni del database primario.

  • Le dimensioni di archiviazione nel database primario devono essere sempre uguali o inferiori alle dimensioni di archiviazione nella replica più piccola.

Contenuti correlati

  • Last updated on