Ridimensionamento delle risorse in Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A: 
Database di Azure per PostgreSQL - Server flessibile
Database di Azure per PostgreSQL : il server flessibile supporta opzioni di ridimensionamento verticale e orizzontale.
Scalabilità verticale
È possibile ridimensionare l'istanza verticalmente aggiungendo altre risorse all'istanza del server flessibile 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 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.
Il livello di calcolo può essere ridimensionato verso l'alto o verso il basso tra Burstable, Utilizzo generico e Ottimizzato per la memoria, per adattarsi alle esigenze del carico di lavoro. In ognuno di questi livelli è disponibile un'ampia selezione di hardware preconfigurato di generazioni diverse e con più o meno CPU e più o meno memoria installata. Tra questa vasta selezione è possibile scegliere quella che supporta i requisiti delle risorse in qualsiasi momento, mantenendo i costi operativi ridotti e adattati alle proprie esigenze.
Il numero di vCore e la memoria installata possono essere ridimensionati verso l'alto o verso il basso. Il livello di archiviazione può anche essere configurato in modo da soddisfare i requisiti della velocità effettiva e delle operazioni di I/O al secondo richieste dal carico di lavoro. Le dimensioni dello spazio di archiviazione possono essere solo aumentate. Inoltre, a seconda dei requisiti, è possibile aumentare o ridurre il periodo di conservazione dei backup compreso tra 7 e 35 giorni.
Queste risorse possono essere ridimensionate usando più interfacce. Ad esempio, è possibile usare portale di Azure o l'interfaccia della riga di comando di Azure.
Nota
Dopo aver aumentato le dimensioni della risorsa di archiviazione assegnata all'istanza, non è possibile ridurla a dimensioni inferiori.
Scalabilità orizzontale
È possibile ridimensionare l'istanza 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.
In una configurazione con scalabilità orizzontale, l'istanza primaria e le repliche di lettura possono anche essere ridimensionate 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, è 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 altre informazioni, vedere Opzioni di archiviazione in Database di Azure per PostgreSQL - Server flessibile.
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 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 Database di Azure per PostgreSQL negli scenari di ridimensionamento, il servizio crea una nuova macchina virtuale per il server con la configurazione aggiornata. Viene quindi sincronizzata con la macchina virtuale che esegue l'istanza e quindi passa al nuovo con una breve interruzione. Quindi un processo in background elimina la vecchia macchina virtuale. Tutto questo processo si verifica senza costi aggiuntivi 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 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.
Nota
Il ridimensionamento 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 limitazioni
- Per il funzionamento del ridimensionamento dei tempi di inattività quasi zero, consentire tutte le connessioni in ingresso e in uscita tra gli indirizzi IP nella subnet delegata, quando si usa la rete integrata di rete virtuale. Se queste connessioni non sono consentite, 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 la 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 normale processo.
- Il ridimensionamento del tempo di inattività quasi zero non funziona se un server inserito in una 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 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 dei dati, tutti i dati in tali tabelle andranno persi dopo il ridimensionamento del tempo di inattività quasi zero.