Repliche in lettura in Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A: Server flessibile di Database di Azure per PostgreSQL
La funzionalità di replica in lettura consente di replicare i dati da un'istanza del server flessibile di 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 alle normali istanze del server flessibile 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 a un server di lettura/scrittura se è necessario il 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 ottimizzate per fornire aggiornamenti quasi in tempo reale dal database primario per la maggior parte dei carichi di lavoro, rendendole 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 di lettura nella stessa area del database primario hanno meno ritardo rispetto alle repliche geografiche, in quanto queste ultime spesso si occupano 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 persistenti, pesanti e a elevato utilizzo di scrittura, l'intervallo di replica può solo continuare ad aumentare senza mai raggiungere 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 nuova creazione 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 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
Un server primario per il server flessibile di Database di Azure per PostgreSQL può essere distribuito in qualsiasi area che supporti il servizio. È possibile creare repliche del server primario all'interno della stessa area o in aree di Azure globali diverse in cui è disponibile il server flessibile di Database di Azure per PostgreSQL. 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 di Database di Azure per PostgreSQL vuota. 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 un ritardo non superiore a 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 al server flessibile di Database di Azure per PostgreSQL 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 server max_wal_size per l'istanza. È possibile tenere traccia del footprint di archiviazione del log delle transazioni usando la metrica Archiviazione log delle transazioni 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 possibilità di burst non è supportato.
Importante
Quando si eseguono operazioni di creazione, eliminazione e promozione della replica, il server primario immette 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 in lettura per il server flessibile di Database di Azure per PostgreSQL, è essenziale comprendere le configurazioni del server che possono essere modificate, quelle ereditate dal server primario e le eventuali limitazioni correlate.
Configurazioni ereditate
Quando viene creata una replica di lettura, questa 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", il livello deve essere lo stesso di quello primario. Per l'operazione di promozione a server indipendente e rimozione dalla replica, può essere uguale o superiore a quello primario.
- Livello di prestazioni (operazioni di I/O al secondo): regolabile.
- Crittografia dei dati: regolabile, includere il passaggio da chiavi gestite dal servizio alle chiavi gestite dal cliente.
Configurazioni dopo la creazione
- Regole del firewall: possono essere aggiunte, eliminate o modificate.
- Livello, dimensioni di archiviazione: per l'operazione "alza di livello al server primario", il livello deve essere lo stesso di quello primario. Per l'operazione di promozione a server indipendente e rimozione dalla replica, può essere uguale o superiore a quello primario.
- Livello di prestazioni (operazioni di I/O al secondo): regolabile.
- Metodo di autenticazione: 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 di 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, questa 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:
- Direttamente all'istanza di replica: è possibile connettersi alla replica usando il nome host e un account utente valido, come si farebbe in una normale istanza del server flessibile 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 postgres
Quando richiesto, immettere la password per l'account dell'utente.
Inoltre, per semplificare il processo di connessione, il portale di Azure fornisce stringhe di connessione pronte all'uso. Queste informazioni sono disponibili nella pagina Connessioni. Includono sia le variabili libpq
che le stringhe di connessione personalizzate per le console Bash.
- Tramite endpoint virtuali: è disponibile un metodo di connessione alternativo che usa gli endpoint virtuali, come descritto in dettaglio 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 nel server flessibile di 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. 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 usata indica se l'accumulo dei file WAL è il motivo principale dell'utilizzo eccessivo dello spazio di archiviazione.
Il server flessibile di Database di Azure per PostgreSQL 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 sulla procedura per la 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 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 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.
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).
Stato della replica
Per monitorare l'avanzamento e lo stato della replica e promuovere l'operazione, vedere la colonna Stato della replica 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/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 |
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. 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: 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.
- Aggiornamento della versione principale sul posto nel server flessibile di Database di Azure per PostgreSQL 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 alla promozionedella replica nella stessa richiesta, non sono supportati. 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.
Nuove repliche
Una replica in lettura viene creata come nuova istanza del server flessibile di 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.
Aumento automatico dell'archiviazione
Quando si configurano repliche in lettura per un'istanza del server flessibile di 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 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 l'istanza del server flessibile di 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 al server primario
Non vengono eseguiti backup da repliche in lettura: i backup non vengono mai eseguiti da server di replica in lettura, indipendentemente dal ruolo precedente.
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.
Restrizioni relative alle operazioni di ripristino: anche se esistono backup precedenti per un server che ha eseguito la transizione a una replica di 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 del server | Backup eseguito | Ripristino consentito |
---|---|---|
Primario | Sì | Sì |
Replica in lettura | No | No |
Replica in lettura promossa a primaria | Sì | Sì |
Alzare di livello a un 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 dal server flessibile di Database di Azure per PostgreSQL.
Importante
La comunicazione bidirezionale tra il server primario e le repliche in lettura è fondamentale per la configurazione del server flessibile di 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.
Gli amministratori possono modificare i parametri del server nel server di replica in 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, 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:
Il server flessibile di Database di Azure per PostgreSQL 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 server primario.
Ridimensionamento: 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 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.