Ridimensionamento delle risorse nel server flessibile di Database di Azure per PostgreSQL

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

Scalabilità verticale

Ridimensionare il server verticalmente aggiungendo altre risorse al server flessibile Database di Azure per PostgreSQL. È possibile aumentare o ridurre il numero di CPU e memoria assegnate.

La velocità effettiva di rete del server dipende dai valori scelti per CPU e memoria.

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

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

Aumenta o riduci il livello di calcolo tra Burstable, Uso generico e Ottimizzato per la memoria in base alle esigenze del tuo carico di lavoro. In ognuno di questi livelli scegliere tra un'ampia selezione di hardware preconfigurato di generazioni diverse con un numero variabile di CPU e quantità di memoria installata. Selezionare l'opzione che supporta i requisiti delle risorse mantenendo i costi operativi ridotti e adattati alle proprie esigenze.

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.

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

Ridimensionamento orizzontale

Database di Azure per PostgreSQL cluster elastici consentono di aumentare orizzontalmente il database per supportare carichi di lavoro di dati che vanno oltre le funzionalità di un singolo server di database. I cluster elastici offrono anche la possibilità di eseguire operazioni parallele contemporaneamente in tutti i nodi di un cluster, aumentando significativamente la velocità effettiva e sbloccando la 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

È possibile scalare orizzontalmente il server creando repliche di lettura. Le repliche in lettura consentono di scalare i carichi di lavoro in lettura su server flessibili separati di Database di Azure per PostgreSQL. Non influiscono sulle prestazioni e sulla disponibilità del server primario.

In una configurazione con scalabilità orizzontale, è anche possibile ridimensionare il server primario e le repliche in lettura verticalmente.

Quando si modifica il numero di vCore o il livello di calcolo, il server viene riavviato 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 richiede da 2 a 10 minuti con scalabilità regolare. Usando la funzionalità di ridimensionamento del tempo di inattività quasi zero, si riduce questa durata a meno di 30 secondi. Questa riduzione del tempo di inattività durante il ridimensionamento delle risorse migliora la disponibilità complessiva dell'istanza del database.

Come funziona

Quando si aggiorna il server flessibile Database di Azure per PostgreSQL negli 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 il server e quindi passa alla nuova macchina virtuale con una breve interruzione. Un processo in background elimina la vecchia macchina virtuale.

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 sia per i server flessibili di Database di Azure per PostgreSQL con disponibilità elevata che per quelli senza disponibilità 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.

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 limitazioni

• 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 server 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