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

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

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

Ridimensionamento verticale: è possibile ridimensionare verticalmente aggiungendo altre risorse all'istanza del server flessibile di Database di Azure per PostgreSQL, ad esempio aumentando il numero di CPU e memoria assegnate dall'istanza. La velocità effettiva di rete dell'istanza dipende dai valori scelti per CPU e memoria.

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

• CPU (vCore).
• Quantità di spazio di archiviazione.
• Periodo di conservazione dei backup.

Il numero di vCore può essere aumentato o ridotto, ma le dimensioni di archiviazione possono essere aumentate solo. È anche possibile ridimensionare il periodo di conservazione dei backup, aumentare o ridurre, da 7 a 35 giorni. Le risorse possono essere ridimensionate usando più strumenti, ad esempio il portale di Azure o l'interfaccia della riga di comando di Azure.

Ridimensionamento orizzontale: è possibile ridimensionare orizzontalmente creando 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.

Quando si modifica il numero di vCore o il livello di calcolo, l'istanza viene riavviata per rendere effettivo il nuovo tipo di 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, è consigliabile 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 altri dettagli, vedere Opzioni di archiviazione in Database di Azure per PostgreSQL - Server flessibile Analogamente, le modifiche al periodo di conservazione dei backup sono un'operazione online. Per migliorare il tempo di riavvio, è consigliabile eseguire operazioni di scalabilità durante le ore di minore attività. Questo approccio riduce il tempo necessario per riavviare il server di database.

Ridimensionamento dei tempi 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 sottoposto a un riavvio 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 nuova funzionalità di ridimensionamento 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 negli scenari di ridimensionamento, viene creata una nuova copia del server (VM) con la configurazione aggiornata. Lo si sincronizza con quello corrente e si passa alla nuova copia con un'interruzione di 30 secondi. Quindi ritiriamo il vecchio server. Il processo viene eseguito senza alcun costo aggiuntivo per l'utente.

Questo processo consente aggiornamenti senza problemi riducendo al minimo i tempi di inattività e garantendo un'efficienza dei costi. Questo processo di ridimensionamento viene attivato quando vengono apportate modifiche ai livelli di archiviazione e calcolo. Non è necessaria alcuna azione da parte del cliente per usare questa funzionalità.

Per i server configurati per la replica 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. Questo periodo non è controllato direttamente dal processo di ridimensionamento. È 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 corretto funzionamento del ridimensionamento dei tempi di inattività quasi zero, abilitare tutte le connessioni in ingresso/in uscita tra gli indirizzi IP nella subnet delegata quando si usa la rete integrata di rete virtuale. Se queste connessioni non sono abilitate, il processo di ridimensionamento dei tempi di inattività quasi zero non funziona e il ridimensionamento avviene tramite il flusso di lavoro di ridimensionamento standard.
• Il ridimensionamento del tempo di inattività quasi zero non funziona se sono presenti vincoli di capacità a livello di area o limiti di quota per le sottoscrizioni dei clienti.
• Il ridimensionamento del tempo di inattività quasi zero non funziona per un server di replica perché è supportato solo nel server primario. Per un server di replica, esegue automaticamente un processo di ridimensionamento regolare.
• Il ridimensionamento del tempo di inattività quasi zero non funziona se un server inserito in una rete virtuale con una subnet delegata non dispone di indirizzi IP utilizzabili sufficienti. Se si dispone di un server autonomo, è necessario un indirizzo IP aggiuntivo. Per un server abilitato per la disponibilità elevata, 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 Abilitazione dell'estensione in un server flessibile.
• Il ridimensionamento dei tempi di inattività quasi zero non funziona con le tabelle non registrate. I clienti che usano tabelle non registrate per i loro dati perderanno tutti i dati in tali tabelle dopo il ridimensionamento del tempo di inattività quasi zero.

Contenuto correlato

• Creare un server flessibile di Database di Azure per PostgreSQL nel portale di Azure.