Condividi tramite

Limiti in Database di Azure per PostgreSQL - Server flessibile

  • Articolo

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

Le sezioni seguenti descrivono i limiti di capacità e funzionalità nel server flessibile di Database di Azure per PostgreSQL. Per informazioni sui livelli di risorse (calcolo, memoria, archiviazione), vedere gli articoli su calcolo e archiviazione.

Numero massimo di connessioni

La tabella seguente illustra il numero massimo di connessioni predefinito per ogni piano tariffario e configurazione vCore. Il server flessibile di Database di Azure per PostgreSQL riserva 15 connessioni per la replica fisica e il monitoraggio dell'istanza del server flessibile di Database di Azure per PostgreSQL. Di conseguenza, il valore per le connessioni utente massime elencate nella tabella è ridotto di 15 rispetto alle connessioni massime totali.

Nome prodotto vCore Dimensioni memoria Numero massimo di connessioni Numero massimo di connessioni utente
Possibilità di burst
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1.718 1.703
B8ms 8 32 GiB 3.437 3.422
B12ms 12 48 GiB 5,000 4.985
B16ms 16 64 GiB 5,000 4.985
B20ms 20 80 GiB 5,000 4.985
Utilizzo generico
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1.718 1.703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 GiB 3.437 3.422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 GiB 5,000 4.985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GiB 5,000 4.985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5,000 4.985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GiB 5,000 4.985
D96ds_v5 / D96ads_v5 96 384 GiB 5,000 4.985
Ottimizzato per la memoria
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1.718 1.703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 GiB 3.437 3.422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 GiB 5,000 4.985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GiB 5,000 4.985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5,000 4.985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5,000 4.985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5,000 4.985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5,000 4.985
E96ds_v5 / E96ads_v5 96 672 GiB 5,000 4.985

Gli slot di connessione riservati, attualmente 15, potrebbero cambiare. È consigliabile verificare regolarmente le connessioni riservate totali nel server. Questo numero viene calcolato sommando i valori dei parametri del server reserved_connections e superuser_reserved_connections. Il numero massimo di connessioni utente disponibili è max_connections - (reserved_connections + superuser_reserved_connections).

Il valore predefinito per il parametro del server max_connections viene calcolato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL, in base al nome del prodotto selezionato per il relativo calcolo. Eventuali modifiche successive della selezione del prodotto al calcolo che supporta il server flessibile non avranno alcun effetto sul valore predefinito per il parametro server max_connections di tale istanza. È consigliabile che, ogni volta che si modifica il prodotto assegnato a un'istanza, si modifichi anche il valore per il parametro max_connections in base ai valori della tabella precedente.

Modifica del valore max_connections

Quando si configura per la prima volta l'istanza del server flessibile di Database di Azure per Postgres, questa determina automaticamente il numero più elevato di connessioni che può gestire contemporaneamente. Questo numero è basato sulla configurazione del server e non può essere modificato.

Tuttavia, è possibile usare l'impostazione max_connections per modificare il numero di connessioni consentite in un determinato momento. Dopo aver modificato questa impostazione, è necessario riavviare il server affinché il nuovo limite inizi a funzionare.

Attenzione

Anche se è possibile aumentare il valore di max_connections oltre l'impostazione predefinita, non è consigliabile farlo.

Le istanze potrebbero riscontrare difficoltà quando il carico di lavoro si espande e richiede più memoria. Con l'aumentare del numero di connessioni, aumenta anche l'utilizzo della memoria. Le istanze con memoria limitata potrebbero riscontrare problemi, ad esempio arresti anomali o latenza elevata. Anche se un valore più elevato per max_connections potrebbe essere accettabile quando la maggior parte delle connessioni è inattiva, l'operazione potrebbe causare problemi di prestazioni significativi man mano che le connessioni si attivano.

Se sono necessarie altre connessioni, è consigliabile usare invece PgBouncer, la soluzione di Azure predefinita per la gestione del pool di connessioni. Usarlo in modalità transazione. Per iniziare, è consigliabile usare valori bassi moltiplicando i vCore in un intervallo da 2 a 5. Successivamente, monitorare attentamente l'utilizzo delle risorse e le prestazioni dell'applicazione per garantire un funzionamento senza problemi. Per informazioni dettagliate su PgBouncer, vedere PgBouncer in Database di Azure per PostgreSQL - Server flessibile.

Quando le connessioni superano il limite, è possibile che venga visualizzato l'errore seguente:

FATAL: sorry, too many clients already.

Quando si usa il server flessibile di Database di Azure per PostgreSQL per un database occupato con un numero elevato di connessioni simultanee, potrebbe verificarsi un notevole carico sulle risorse. Questo sforzo può comportare un utilizzo elevato della CPU, soprattutto quando vengono stabilite contemporaneamente molte connessioni e quando le connessioni hanno una durata breve (inferiore a 60 secondi). Questi fattori possono influire negativamente sulle prestazioni complessive del database aumentando il tempo impiegato per l'elaborazione delle connessioni e delle disconnessioni.

Tenere presente che ogni connessione nel server flessibile di Database di Azure per PostgreSQL, indipendentemente dal fatto che sia inattiva o attiva, utilizza una quantità significativa di risorse dal database. Questo utilizzo può causare problemi di prestazioni al di là di un utilizzo elevato della CPU, ad esempio la contesa del disco e dei blocchi. L'articolo Numero di connessioni al database nel wiki di PostgreSQL illustra in modo più dettagliato questo argomento. Per altre informazioni, vedere Identificare e risolvere le prestazioni di connessione nel server flessibile di Database di Azure per PostgreSQL.

Limiti funzionali

Le sezioni seguenti elencano le considerazioni relative a ciò che è supportato o meno nel server flessibile di Database di Azure per PostgreSQL.

Operazioni di scalabilità

  • Al momento, per aumentare le prestazioni di archiviazione del server è necessario riavviarlo.
  • L'archiviazione server può essere ridimensionata solo in incrementi doppi. Per informazioni dettagliate, vedere Archiviazione.
  • La riduzione delle dimensioni di archiviazione del server non è attualmente supportata. L'unico modo per farlo è eseguire un dump e ripristino in una nuova istanza del server flessibile di Database di Azure per PostgreSQL.

Storage

  • Dopo aver configurato le dimensioni di archiviazione, non è possibile ridurle. È necessario creare un nuovo server con le dimensioni di archiviazione desiderate, eseguire un'operazione di dump e ripristino manuale e ripristinare ed eseguire la migrazione dei database al nuovo server.
  • Quando l'utilizzo dello spazio di archiviazione raggiunge il 95% o se la capacità disponibile è inferiore a 5 GiB (in base al valore più elevato), il server viene automaticamente impostato sulla modalità di sola lettura per evitare errori associati a situazioni di riempimento del disco. In rari casi, se il tasso di crescita dei dati supera il tempo necessario per passare alla modalità di sola lettura, il server potrebbe comunque esaurire lo spazio di archiviazione. È possibile abilitare l'aumento automatico dell'archiviazione per evitare questi problemi e ridimensionare automaticamente l'archiviazione in base alle esigenze del carico di lavoro.
  • È consigliabile impostare regole di avviso per storage used o storage percent quando superano determinate soglie in modo da poter intervenire in modo proattivo, ad esempio aumentando le dimensioni di archiviazione. Ad esempio, è possibile impostare un avviso se la percentuale di archiviazione supera l'80%.
  • Se si usa la replica logica e se il sottoscrittore corrispondente non esiste più, è necessario eliminare lo slot di replica logica nel server primario. In caso contrario, i file di registrazione write-ahead (WAL) si accumulano nel database primario e riempiono lo spazio di archiviazione. Se l'archiviazione supera una determinata soglia e se lo slot di replica logica non è in uso (a causa di un sottoscrittore non disponibile), il server flessibile di Database di Azure per PostgreSQL elimina automaticamente lo slot di replica logica inutilizzato. Questa azione rilascia i file WAL accumulati e impedisce al server di diventare non disponibile nel momento in cui lo spazio di archiviazione risulta pieno.
  • Non è supportata la creazione di spazi tabella. Se si sta creando un database, non specificare un nome di spazio di tabella. Il server flessibile di Database di Azure per PostgreSQL usa quello predefinito ereditato dal database modello. Non è sicuro fornire uno spazio di tabella come quello temporaneo, perché non è possibile assicurarsi che tali oggetti rimangano persistenti dopo eventi come i failover a disponibilità elevata e i riavvii del server.

Rete

  • Lo spostamento da e verso una rete virtuale non è attualmente supportato.
  • La combinazione dell'accesso pubblico con la distribuzione in una rete virtuale non è attualmente supportata.
  • Le regole del firewall non sono supportate nelle reti virtuali. È invece possibile usare i gruppi di sicurezza di rete.
  • I server di database di accesso pubblico possono connettersi alla rete Internet pubblica; ad esempio tramite postgres_fdw. Non è possibile limitare l'accesso. I server nelle reti virtuali possono avere accesso in uscita limitato tramite gruppi di sicurezza di rete.

Disponibilità elevata

Zone di disponibilità

  • Lo spostamento manuale dei server in una zona di disponibilità diversa non è attualmente supportato. Tuttavia, usando la zona di disponibilità preferita come zona di standby, è possibile attivare la disponibilità elevata. Dopo aver stabilito la zona di standby, è possibile eseguirne il failover e quindi disattivare la disponibilità elevata.

Motore Postgres, estensioni e PgBouncer

  • Postgres 10 e versioni precedenti non sono supportati, perché la community open source li ha ritirati. Se è necessario usare una di queste versioni, è necessario usare l'opzione Server singolo di Database di Azure per PostgreSQL, che supporta le versioni principali precedenti 9.5, 9.6 e 10.
  • Il server flessibile di Database di Azure per PostgreSQL supporta tutte le estensioni contrib e altro ancora. Per altre informazioni, vedere Estensioni di PostgreSQL.
  • Il pool di connessioni PgBouncer predefinito non è attualmente disponibile per i server con possibilità di burst.

Operazioni di arresto/avvio

  • Dopo aver arrestato l'istanza del server flessibile di Database di Azure per PostgreSQL, viene avviata automaticamente dopo 7 giorni.

Manutenzione pianificata

  • È possibile modificare la finestra di manutenzione personalizzata in qualsiasi giorno/ora della settimana. Tuttavia, le modifiche apportate dopo la ricezione della notifica di manutenzione non avranno alcun impatto sulla manutenzione successiva. Le modifiche diventano effettive solo con la manutenzione pianificata mensile seguente.

Backup server

  • Il sistema gestisce i backup. Attualmente non è possibile eseguire manualmente i backup. È consigliabile utilizzare invece pg_dump.

  • Il primo snapshot è un backup completo e gli snapshot consecutivi sono backup differenziali. Il backup differenziale esegue il backup solo dei dati modificati dopo l'ultimo backup dello snapshot.

    Ad esempio, se le dimensioni del database sono pari a 40 GB e l'archiviazione di cui è stato effettuato il provisioning è di 64 GB, il primo backup dello snapshot sarà di 40 GB. Ora, se si modificano 4 GB di dati, le dimensioni del backup differenziale dello snapshot successivo saranno di soli 4 GB. I log delle transazioni (log write-ahead) sono separati dai backup completi e differenziali e vengono archiviati continuamente.

Ripristino del server

  • Quando si usa la funzionalità di ripristino temporizzato, il nuovo server viene creato con le stesse configurazioni di calcolo e archiviazione del server su cui si basa.
  • I server di database nelle reti virtuali vengono ripristinati nelle stesse reti virtuali quando si esegue il ripristino da un backup.
  • Il nuovo server creato durante un ripristino non dispone delle regole del firewall presenti nel server originale. È necessario creare regole del firewall separate per il nuovo server.
  • Il ripristino in una sottoscrizione diversa non è supportato. Come soluzione alternativa, è possibile ripristinare il server all'interno della stessa sottoscrizione e quindi eseguire la migrazione del server ripristinato a una sottoscrizione diversa.

Contenuto correlato