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à in Database di Azure per PostgreSQL server flessibile. Per informazioni sui livelli di risorse (calcolo, memoria o archiviazione), vedere l'articolo Calcolo e archiviazione .

Numero massimo di connessioni

La tabella seguente mostra il numero massimo predefinito di connessioni per ogni piano tariffario e configurazione vCore. Database di Azure per PostgreSQL server flessibile riserva 15 connessioni per la replica fisica e il monitoraggio dell'istanza del server flessibile 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
Burstable
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 a 15, potrebbero cambiare. È consigliabile verificare regolarmente le connessioni riservate totali nel server. Questo numero viene calcolato sommando i valori dei parametri del reserved_connections server e superuser_reserved_connections . Il numero massimo di connessioni utente disponibili è max_connections - (reserved_connections + superuser_reserved_connections).

Il valore predefinito per il max_connections parametro server viene calcolato quando si esegue il provisioning dell'istanza di Database di Azure per PostgreSQL server flessibile, 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 max_connections parametro server di tale istanza. È consigliabile modificare ogni volta che il prodotto assegnato a un'istanza di viene modificato anche in max_connections 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, 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, è 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, può causare problemi di prestazioni significativi dopo che sono diventati attivi.

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 conservativi moltiplicando i vCore nell'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 Database di Azure per PostgreSQL server flessibile per un database occupato con un numero elevato di connessioni simultanee, potrebbe verificarsi un notevole sforzo 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 in Database di Azure per PostgreSQL server flessibile, indipendentemente dal fatto che sia inattiva o attiva, utilizza una quantità significativa di risorse dal database. Questo utilizzo può causare problemi di prestazioni oltre l'utilizzo elevato della CPU, ad esempio la contesa del disco e del blocco. L'articolo Numero di Connessione di database nel wiki di PostgreSQL illustra in modo più dettagliato questo argomento. Per altre informazioni, vedere Identificare e risolvere le prestazioni di connessione in Database di Azure per PostgreSQL server flessibile.

Limiti funzionali

Nelle sezioni seguenti vengono elencate le considerazioni relative a ciò che è e non è supportato in Database di Azure per PostgreSQL server flessibile.

Operazioni di scalabilità

  • Al momento, per aumentare le prestazioni di archiviazione del server è necessario riavviare il server.
  • È possibile ridimensionare l'archiviazione del server solo in incrementi 2x. Per informazioni dettagliate, vedere Calcolo e archiviazione.

Storage

  • Dopo aver configurato le dimensioni di archiviazione, non è possibile ridurla. È necessario creare un nuovo server con le dimensioni di archiviazione desiderate, eseguire un'operazione di dump e ripristino manuale 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 (a differenza di più), il server viene automaticamente impostato sulla modalità di sola lettura per evitare errori associati a situazioni con registrazione completa 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, è necessario eliminare lo slot di replica logica nel server primario se il sottoscrittore corrispondente non esiste più. In caso contrario, i file di registrazione write-ahead 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), Database di Azure per PostgreSQL server flessibile elimina automaticamente lo slot di replica logica inutilizzato. Questa azione rilascia i file WAL accumulati e impedisce al server di diventare non disponibile perché lo spazio di archiviazione viene riempito.
  • Non è supportata la creazione di spazi tabella. Se si sta creando un database, non specificare un nome di spazio di tabella. Database di Azure per PostgreSQL server flessibile 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 Database di Azure per PostgreSQL server singolo, che supporta le versioni principali precedenti 9.5, 9.6 e 10.
  • Database di Azure per PostgreSQL server flessibile supporta tutte le contrib estensioni e altro ancora. Per altre informazioni, vedere Estensioni di PostgreSQL.
  • Il pool di connessioni PgBouncer predefinito non è attualmente disponibile per i server con burst.

Operazioni di arresto/avvio

  • Dopo aver arrestato l'istanza del server flessibile 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 del server

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

  • 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 esistenti nel server originale. È necessario creare regole del firewall separatamente 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.

Passaggi successivi