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

  • Articolo

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

La funzionalità di replica in lettura consente di replicare i dati da un'istanza del server flessibile Database di Azure per PostgreSQL a una replica di sola lettura. Le repliche vengono aggiornate in modo asincrono con 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 gestiti in modo simile a quello normale Database di Azure per PostgreSQL istanze di server flessibili. 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 a un server di lettura/scrittura se è necessario il ripristino di emergenza.

Uno scenario tipico consiste nell'avere carichi di lavoro bi e analitici che usano la replica di 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 destinati a scenari di replica sincroni 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 alle ore. In genere, le repliche di lettura nella stessa area del database primario hanno meno ritardo rispetto alle repliche geografiche, in quanto 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.

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 a elevato utilizzo di scrittura persistente, il ritardo di replica potrebbe continuare a crescere e potrebbe essere in grado di raggiungere solo il database primario. Questo potrebbe anche aumentare l'utilizzo dell'archiviazione nel database primario perché i file WAL vengono eliminati solo una volta ricevuti nella replica. Se questa situazione persiste, l'eliminazione e la ricreazione della replica di lettura dopo il completamento dei carichi di lavoro a elevato utilizzo di scrittura, è possibile riportare la replica a uno stato valido per il 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 completo del carico di lavoro dell'app attraverso i picchi e i periodi non di picco per valutare il possibile ritardo e l'obiettivo RTO/RPO previsto in vari punti del ciclo del carico di lavoro.

Creare una replica

Un server primario per Database di Azure per PostgreSQL server flessibile può essere distribuito in qualsiasi area che supporta il servizio. È possibile creare repliche del server primario all'interno della stessa area o in aree di Azure globali diverse in cui è disponibile Database di Azure per PostgreSQL server flessibile. La possibilità di creare repliche ora si estende ad alcune aree speciali di Azure. Vedere l'articolo Replica geografica per un elenco di aree speciali in cui è possibile creare repliche.

Quando si avvia il flusso di lavoro di creazione della replica, viene creata un'istanza del server flessibile vuota Database di Azure per PostgreSQL. Il nuovo server viene riempito con i dati nel server primario. Per la creazione di repliche nella stessa area, viene usato un approccio snapshot. Di conseguenza, il tempo di creazione è indipendente dalle dimensioni dei dati. Le repliche geografiche vengono create usando il backup di base dell'istanza primaria, che viene quindi trasmesso in rete; pertanto, il tempo di creazione potrebbe variare da minuti a diverse ore, a seconda delle dimensioni primarie.

La replica viene considerata creata correttamente solo quando vengono soddisfatte due condizioni: l'intero backup dell'istanza primaria deve essere copiato nella replica e i log delle transazioni devono essere sincronizzati con non 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, è consigliabile evitare di creare repliche durante la migrazione da altre origini a Database di Azure per PostgreSQL server flessibile o durante operazioni di caricamento bulk elevato. Se si esegue la migrazione dei dati o si caricano grandi quantità di dati al momento, è consigliabile completare prima questa attività. Al termine, è possibile avviare la configurazione delle repliche. Al termine dell'operazione di migrazione o caricamento bulk, verificare se le dimensioni del log delle transazioni sono state restituite alle dimensioni normali. In genere, le dimensioni del log delle transazioni devono essere vicine al valore definito nel parametro del server max_wal_size per l'istanza. È possibile tenere traccia del footprint di archiviazione del log delle transazioni usando la metrica Log delle transazioni Archiviazione usata, che fornisce informazioni dettagliate sulla quantità di spazio di archiviazione usato 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 entrerà in uno stato di aggiornamento. Durante questo periodo di tempo, le operazioni di gestione del server, ad esempio la modifica dei parametri del server, la modifica delle opzioni di disponibilità elevata o l'aggiunta o la rimozione di firewall non saranno disponibili. È importante notare che lo stato di aggiornamento influisce solo sulle operazioni di gestione del server e non influisce sulle operazioni del piano dati. Ciò significa che il server di database rimarrà completamente funzionante e in grado di accettare connessioni, nonché di gestire il traffico di lettura e scrittura.

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

Gestione della configurazione

Quando si configurano repliche di lettura per Database di Azure per PostgreSQL server flessibile, è essenziale comprendere le configurazioni del server che possono essere modificate, quelle ereditate dal server primario ed eventuali limitazioni correlate.

Configurazioni ereditate

Quando viene creata una replica di lettura, eredita configurazioni server specifiche dal server primario. Queste configurazioni possono essere modificate durante la creazione della replica o dopo la configurazione. Tuttavia, impostazioni specifiche, ad esempio il backup geografico, non verranno replicate nella replica di lettura.

Configurazioni durante la creazione della replica

  • Livello, dimensioni di archiviazione: per l'operazione "alza di livello al server primario", deve essere uguale a quello primario. Per l'operazione di promozione a server indipendente e rimozione dalla replica, può essere uguale o superiore a quella primaria.
  • Livello di prestazioni (IOPS): regolabile.
  • Crittografia dei dati: regolabile, includere lo spostamento da chiavi gestite dal servizio a chiavi gestite dal cliente.

Configurazioni dopo la creazione

  • Regole del firewall: è possibile aggiungere, eliminare o modificare.
  • Livello, dimensioni di archiviazione: per l'operazione "alza di livello al server primario", deve essere uguale a quello primario. Per l'operazione di promozione a server indipendente e rimozione dalla replica, può essere uguale o superiore a quella primaria.
  • Livello di prestazioni (IOPS): regolabile.
  • Metodo di autenticazione: le opzioni regolabili includono il passaggio dall'autenticazione PostgreSQL a Microsoft Entra.
  • Parametri del server: la maggior parte è regolabile. Tuttavia, quelli che influiscono sulle dimensioni della memoria condivisa devono essere allineati con il database primario, soprattutto per i potenziali scenari di "promozione al server primario". Per l'operazione "promuovere il server indipendente e rimuovere dalla replica", questi parametri devono essere uguali o superare quelli nel database primario.
  • Pianificazione della manutenzione: regolabile.

Funzionalità non supportate nelle repliche in lettura

Alcune funzionalità sono limitate ai server primari e non possono essere configurate nelle repliche in lettura. tra cui:

  • Backup, inclusi i backup geografici.
  • Disponibilità elevata

Se l'istanza del server flessibile Database di Azure per PostgreSQL di origine viene crittografata con chiavi gestite dal cliente, vedere la documentazione per altre considerazioni.

Connessione a una replica

Quando si crea una replica, eredita le regole del firewall o l'endpoint servizio di rete virtuale del server primario. Queste regole potrebbero essere modificate durante la creazione della replica e in qualsiasi momento successivo.

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.

Esistono due metodi per connettersi alla replica:

  • Diretto all'istanza di replica: è possibile connettersi alla replica usando il nome host e un account utente valido, come si farebbe in un'istanza normale del 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.

Inoltre, per semplificare il processo di connessione, il portale di Azure fornisce stringa di connessione pronti all'uso. Queste informazioni sono disponibili nella pagina Connessione. Comprendono sia variabili che libpq stringa di connessione personalizzate per le console Bash.

  • Tramite endpoint virtuali: esiste un metodo di connessione alternativo che usa gli endpoint virtuali, come descritto nell'articolo Endpoint virtuali. Usando gli endpoint virtuali, è possibile configurare l'endpoint di sola lettura in modo che punti in modo coerente 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 server flessibile 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. Ciò consente di evitare che le repliche non vengano sincronizzate perché evita l'eliminazione di segmenti WAL nel database primario prima che vengano inviate alle repliche. Lo svantaggio dell'approccio è il rischio di uscire dallo spazio nel database primario nel caso in cui lo slot di replica rimanga inattivo per un periodo di tempo prolungato. In tali situazioni, la replica primaria accumula i file WAL che causano una crescita incrementale dell'utilizzo dello spazio di archiviazione. Quando l'utilizzo dello spazio di archiviazione raggiunge il 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 con registrazione completa del disco.
Di conseguenza, il monitoraggio dello stato degli slot di replica e ritardo della replica è fondamentale per le repliche in lettura.

È consigliabile 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 Log delle transazioni Archiviazione Used indica se l'accumulo dei file WAL è il motivo principale dell'utilizzo eccessivo dello spazio di archiviazione.

Database di Azure per PostgreSQL server flessibile fornisce due metriche per il monitoraggio della replica. Le due metriche sono Max Physical Replication Lag e Read Replica Lag. Per informazioni su come visualizzare queste metriche, vedere la sezione Monitorare una replica dell'articolo Procedura di lettura della replica.

La metrica Max Physical Replication Lag (Ritardo replica fisica massima) 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. 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 l'ora dell'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 informare l'utente quando il ritardo della replica raggiunge un valore 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.

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.

Stato replica

Per monitorare lo stato e lo stato della replica e promuovere l'operazione, fare riferimento alla colonna Stato replica nella 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 replica contenitore delle proprietà.

Ecco i valori possibili:

Stato replica Descrizione Alzare di livello l'ordine Lettura dell'ordine di creazione della replica
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/D
Provisioning È in corso il provisioning della replica di lettura e la replica tra i due server deve ancora essere avviata. Fino al completamento del provisioning, non è possibile connettersi alla replica di lettura. N/D 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
Catchup 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 è stata connessa correttamente al database primario. Se i server vengono arrestati ma sono stati connessi correttamente prima, lo stato rimane attivo. 4 4
Rotto 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. Eliminare la replica e ricreare la replica per risolvere il problema." N/D N/D

Informazioni su come monitorare la replica.

Considerazioni

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

  • Operazioni di risparmio energia: le operazioni di risparmio energia, incluse le azioni di avvio e arresto, possono essere applicate sia ai server primario che a quello di replica. Tuttavia, per mantenere l'integrità del sistema, deve essere seguita 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 il server dispone di repliche in lettura, è necessario eliminare le repliche di lettura prima di eliminare il server primario.
  • L'aggiornamento della versione principale sul posto in Database di Azure per PostgreSQL server flessibile richiede la rimozione di tutte le repliche in lettura attualmente abilitate nel server. Dopo l'eliminazione delle repliche, il server primario può essere aggiornato alla versione principale desiderata. Al termine dell'aggiornamento, è possibile ricreare le repliche per riprendere il processo di replica.
  • SSD Premium v2: a partire dalla versione corrente, se il server primario usa SSD Premium v2 per l'archiviazione, la creazione di repliche in lettura non è supportata.
  • Reimpostazione della password amministratore: la reimpostazione della password amministratore nel server di replica non è attualmente supportata. Inoltre, l'aggiornamento della password amministratore insieme all'innalzamento di livello dell'operazione di replica nella stessa richiesta non è supportato. Se si vuole eseguire questa operazione, è necessario alzare di livello il server di replica e quindi aggiornare la password nel server appena alzato di livello separatamente.

Nuove repliche

Una replica in lettura viene creata come nuova istanza del server flessibile Database di Azure per PostgreSQL. Un server esistente non può essere impostato come replica. Non è possibile creare una replica di un'altra replica di lettura, ovvero la replica a catena non è supportata.

Spostamento di risorse

Gli utenti possono creare repliche in lettura in un gruppo di risorse diverso da quello primario. Tuttavia, lo spostamento delle repliche in lettura in un altro gruppo di risorse dopo la creazione non è supportato. Inoltre, lo spostamento delle repliche in una sottoscrizione diversa e lo spostamento della replica primaria con repliche in lettura in un altro gruppo di risorse o sottoscrizione, non è supportato.

Archiviazione aumento automatico

Quando si configurano repliche in lettura per un'istanza del server flessibile Database di Azure per PostgreSQL, è essenziale assicurarsi che l'impostazione di aumento automatico dell'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 dell'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 l'istanza del server flessibile Database di Azure per PostgreSQL, è essenziale tenere presente il ruolo corrente e precedente del server in diversi scenari di promozione. Ecco i punti chiave da ricordare:

Alzare di livello il server primario

  1. Non vengono eseguiti backup da repliche in lettura: i backup non vengono mai eseguiti dai server di replica in lettura, indipendentemente dal ruolo precedente.

  2. Conservazione dei backup precedenti: se un server era una volta primario e ha backup eseguiti durante tale periodo, tali backup vengono mantenuti. Verranno conservati fino al periodo di conservazione definito dall'utente.

  3. Restrizioni relative all'operazione di ripristino: anche se esistono backup passati per un server che ha eseguito la transizione a una replica in lettura, le operazioni di ripristino sono limitate. È possibile avviare un'operazione di ripristino solo quando il server è stato alzato di livello al ruolo primario.

Per maggiore chiarezza, ecco una tabella che illustra questi punti:

Ruolo server Backup eseguito Ripristino consentito
Primario Sì Sì
Replica in lettura No No
Replica di lettura promossa a primaria Sì Sì

Alzare di livello il server indipendente e rimuovere dalla replica

Mentre il server è una replica di lettura, non vengono eseguiti backup. Tuttavia, una volta alzato di livello a un server indipendente, sia il server alzato di livello che il server primario hanno backup eseguiti e i ripristini sono consentiti in entrambi.

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 del server flessibile Database di Azure per PostgreSQL. È necessario disporre di un provisioning per inviare e ricevere traffico sulla porta di destinazione 5432 all'interno della subnet della rete virtuale di Azure.

Il requisito precedente non solo facilita il processo di sincronizzazione, ma garantisce anche il corretto funzionamento del meccanismo di promozione in cui le repliche potrebbero dover comunicare in ordine inverso, dalla replica alla replica primaria, soprattutto durante la promozione alle operazioni primarie. Inoltre, le connessioni all'account di archiviazione di Azure che archivia gli archivi di registrazione write-ahead (WAL) devono essere autorizzate a mantenere la durabilità dei dati e abilitare 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 di Azure e reti virtuali all'interno di un contesto di rete privata, vedere la pagina Replica tra aree di 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.

Poiché la gestione dell'integrità e delle funzionalità del server primario è una priorità, in questi casi perimetrali lo slot di replica potrebbe essere eliminato 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.

È essenziale monitorare attentamente l'utilizzo dell'archiviazione e il ritardo della replica e intraprendere azioni necessarie per attenuare i potenziali problemi prima dell'escalation.

Parametri del server

Quando viene creata una replica di lettura, eredita i parametri del server dal server primario. Si tratta di garantire un punto di partenza coerente e affidabile. Tuttavia, tutte le modifiche apportate ai parametri del server nel server primario 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 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 del server.

Amministrazione istrator può modificare i parametri del server 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_transactionsmax_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, questi particolari parametri devono essere sempre impostati su valori equivalenti o superiori a quelli configurati nel server primario.

Ridimensiona

È possibile aumentare e ridurre le risorse di calcolo (vCore), modificando il livello di servizio da Utilizzo generico a Ottimizzato per la memoria (o viceversa) e aumentando l'archiviazione, ma si applicano le avvertenze seguenti.

Per il ridimensionamento delle risorse di calcolo:

  • Database di Azure per PostgreSQL server flessibile richiede che diversi parametri nelle repliche siano maggiori o uguali all'impostazione nel 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 database primario.

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

  • Il calcolo nel database primario deve essere sempre uguale o inferiore al calcolo nella replica più piccola.

Per il ridimensionamento dell'archiviazione:

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

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

Contenuto correlato