Ridimensionamento delle risorse in Database di Azure per PostgreSQL

Un'istanza del server flessibile di Database di Azure per PostgreSQL supporta le opzioni di ridimensionamento verticale e orizzontale.

Scalabilità verticale

È possibile ridimensionare l'istanza verticalmente aggiungendo altre risorse all'istanza del server flessibile di Database di Azure per PostgreSQL. È possibile aumentare o ridurre il numero di CPU e memoria assegnate.

La velocità effettiva di rete dell'istanza dipende dai valori scelti per CPU e memoria.

Dopo aver creato un'istanza del server flessibile di Azure Database per PostgreSQL, è possibile ridimensionare in modo indipendente:

• Livello di calcolo e SKU.
• Livello di archiviazione e dimensioni.
• Periodo di conservazione dei backup.

È possibile aumentare o ridurre il livello di calcolo tra Burstable, Utilizzo generico e Ottimizzato per la memoria per adattarsi alle esigenze del carico di lavoro. In ognuno di questi livelli è possibile scegliere tra un'ampia gamma di hardware preconfigurato di generazioni diverse con un numero variabile di CPU e quantità di memoria installata. È possibile selezionare l'opzione che supporta i requisiti delle risorse mantenendo i costi operativi ridotti e adattati alle proprie esigenze.

È possibile ridimensionare il numero di vCore e la memoria installata verso l'alto o verso il basso. È anche possibile configurare il livello di archiviazione verso l'alto o verso il basso per soddisfare i requisiti di velocità effettiva e operazioni di I/O al secondo richiesti dal carico di lavoro. È possibile aumentare solo le dimensioni di archiviazione. A seconda dei requisiti, è possibile aumentare o ridurre il periodo di conservazione dei backup compreso tra 7 e 35 giorni.

È possibile ridimensionare queste risorse usando più interfacce. Ad esempio, è possibile usare il portale di Azure o l'interfaccia della riga di comando di Azure.

Note

Dopo aver aumentato le dimensioni dello spazio di archiviazione assegnato all'istanza, non è possibile ridurle a dimensioni inferiori.

Scalabilità orizzontale

I cluster elastici di Database di Azure per PostgreSQL consentono di aumentare orizzontalmente il database per supportare carichi di lavoro di dati che si estendono oltre le funzionalità di una singola istanza di database. I cluster elastici consentono anche di eseguire operazioni parallele contemporaneamente in tutti i nodi di un cluster, aumentando significativamente la velocità effettiva e sbloccando una latenza ultra bassa. I cluster elastici offrono due modelli di partizionamento orizzontale delle tabelle: partizionamento orizzontale basato su righe e partizionamento orizzontale basato su schema.

Ridimensionamento delle repliche in lettura

Un altro approccio alla scalabilità orizzontale dell'istanza consiste nella creazione di repliche in lettura. Le repliche in lettura consentono di ridimensionare i carichi di lavoro di lettura in istanze server flessibili di Database di Azure per PostgreSQL separate. Non influiscono sulle prestazioni e sulla disponibilità dell'istanza primaria.

In una configurazione con scalabilità orizzontale, è anche possibile ridimensionare l'istanza primaria e le repliche di lettura verticalmente.

Quando si modifica il numero di vCore o il livello di calcolo, l'istanza viene riavviata in modo che il nuovo hardware assegnato inizi a eseguire il carico di lavoro del server. Durante questo periodo, il sistema passa al nuovo tipo di server. Non è possibile stabilire nuove connessioni e viene eseguito il rollback di tutte le transazioni di cui non è stato eseguito il commit.

Il tempo complessivo necessario per riavviare il server dipende dal processo di ripristino di arresto anomalo del sistema e dall'attività del database al momento del riavvio. Il riavvio richiede in genere un minuto o meno, ma può essere di alcuni minuti. L'intervallo dipende dall'attività transazionale all'avvio del riavvio.

Se l'applicazione è sensibile alla perdita di transazioni in anteprima che potrebbero verificarsi durante il ridimensionamento del calcolo, implementare un modello di ripetizione dei tentativi di transazione.

La scalabilità dell'archiviazione non richiede un riavvio del server nella maggior parte dei casi. Per altre informazioni, vedere Opzioni di archiviazione in Database di Azure per PostgreSQL.

Le modifiche al periodo di conservazione del backup sono un'operazione online.

Per migliorare il tempo di riavvio, eseguire operazioni di scalabilità durante le ore di minore attività. Questo approccio riduce il tempo necessario per riavviare il server di database.

Ridimensionamento del tempo di inattività quasi zero

Il ridimensionamento dei tempi di inattività quasi zero è una funzionalità progettata per ridurre al minimo i tempi di inattività quando si modificano i livelli di archiviazione e calcolo. Se si modifica il numero di vCore o si modifica il livello di calcolo, il server viene riavviato per applicare la nuova configurazione. Durante questa transizione al nuovo server, non è possibile stabilire nuove connessioni.

In genere, questo processo può richiedere da 2 a 10 minuti con scalabilità regolare. Con la funzionalità di scalabilità del tempo di inattività quasi zero, questa durata viene ridotta a meno di 30 secondi. Questa riduzione del tempo di inattività durante il ridimensionamento delle risorse migliora la disponibilità complessiva dell'istanza del database.

Funzionamento

Quando si aggiorna l'istanza del server flessibile di Database di Azure per PostgreSQL in scenari di ridimensionamento, il servizio crea una nuova macchina virtuale per il server con la configurazione aggiornata. Quindi si sincronizza con la macchina virtuale che esegue l'istanza e quindi passa alla nuova macchina virtuale con una breve interruzione. Un processo in background elimina quindi la macchina virtuale precedente.

Questo processo consente aggiornamenti semplici con tempi di inattività minimi e viene attivato automaticamente quando si modificano i livelli di archiviazione o di calcolo. Non è necessario eseguire alcuna azione per usare questa funzionalità. Questa funzionalità è supportata per le istanze del server flessibile di Database di Azure per PostgreSQL sia a disponibilità elevata sia a disponibilità non elevata.

Per le configurazioni con scalabilità orizzontale, costituite da un server primario e da una o più repliche in lettura, le operazioni di ridimensionamento devono seguire una sequenza specifica per garantire la coerenza dei dati e ridurre al minimo i tempi di inattività. Per informazioni dettagliate su tale sequenza, vedere ridimensionamento con repliche in lettura.

Note

La scalabilità del tempo di inattività quasi zero è il tipo di operazione predefinito. Quando vengono rilevate le limitazioni seguenti, il sistema passa al ridimensionamento regolare, che comporta un tempo di inattività maggiore rispetto al ridimensionamento dei tempi di inattività quasi zero.

Precise aspettative di tempo di inattività

• Durata del tempo di inattività: nella maggior parte dei casi, il tempo di inattività varia da 10 a 30 secondi.
• Altre considerazioni: dopo un evento di ridimensionamento, è previsto un periodo DNS intrinseco Time-To-Live (TTL) di circa 30 secondi. Il processo di ridimensionamento non controlla direttamente questo periodo. È una parte standard del comportamento DNS. Dal punto di vista dell'applicazione, il tempo di inattività totale riscontrato durante il ridimensionamento potrebbe essere compreso tra 40 e 60 secondi.

Considerazioni e limiti

• Per il funzionamento del ridimensionamento dei tempi di inattività quasi nulli, consentire tutte le connessioni in ingresso e in uscita tra gli indirizzi IP nella subnet delegata, quando si usa la rete virtuale integrata. Se queste connessioni non sono consentite, il processo di ridimensionamento del tempo di inattività quasi zero non funziona e il ridimensionamento avviene tramite il flusso di lavoro di scalabilità standard.
• La scalabilità dei tempi di inattività quasi zero non funziona se sono presenti vincoli di capacità a livello di area o limiti di quota nella sottoscrizione.
• Il ridimensionamento del tempo di inattività quasi zero non funziona per un server di replica perché è supportato solo nel server primario. Per i server di replica, l'operazione di ridimensionamento passa automaticamente attraverso il processo normale.
• La scalabilità dei tempi di inattività quasi zero non funziona se un server inserito nella rete virtuale non dispone di indirizzi IP utilizzabili sufficienti nella subnet delegata. Se si dispone di un server autonomo, è necessario un indirizzo IP aggiuntivo. Per un'istanza con disponibilità elevata abilitata, sono necessari due indirizzi IP aggiuntivi.
• Gli slot di replica logica non vengono mantenuti durante un evento di failover di tempo di inattività quasi zero. Per mantenere gli slot di replica logici e garantire la coerenza dei dati dopo un'operazione di scalabilità, usare l'estensione pg_failover_slot. Per altre informazioni, vedere l'abilitazione dell'estensione pg_failover_slots in un'istanza del server flessibile.
• Il ridimensionamento dei tempi di inattività quasi zero non funziona con le tabelle non registrate. Se si usano tabelle non registrate per uno qualsiasi dei dati, tutti i dati in tali tabelle andranno persi dopo il ridimensionamento del tempo di inattività quasi zero.
• Quasi zero non funziona se si ridimensiona il calcolo del server da o verso una dimensione di calcolo di 1 o 2 vCore del livello con possibilità di burst.

Contenuti correlati

• Gestire Database di Azure per PostgreSQL