Condividi tramite

Limiti in Database di Azure per PostgreSQL

Le sezioni seguenti descrivono i limiti di capacità e funzionalità per le istanze del 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. Un’istanza del server flessibile di Database PostgreSQL di Azure riserva 15 connessioni per la replica fisica e il monitoraggio dell'istanza del server flessibile di Database PostgreSQL di Azure. Di conseguenza, la tabella riduce il valore per le connessioni utente massime 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
Con ottimizzazione 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 sono attualmente di 15, ma possono 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 sistema calcola il valore predefinito per il max_connections parametro del server 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 l'istanza non avranno alcun effetto sul valore predefinito per il max_connections parametro server 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. La configurazione del server determina questo numero e non è possibile modificarlo.

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 diventi effettivo.

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 regolare. Per informazioni dettagliate su PgBouncer, vedere PgBouncer in Database di Azure per PostgreSQL.

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

FATAL: sorry, too many clients already.

Quando si usa un'istanza del 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.

Ogni connessione in un'istanza del 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 articolo. Per altre informazioni, vedere Identificare e risolvere le prestazioni di connessione in Azure Postgres.

Limitazioni funzionali

Le sezioni seguenti elencano le considerazioni relative a ciò che è e non sono supportate per le istanze del server flessibile di Database di Azure per PostgreSQL.

Operazioni di ridimensionamento

  • Al momento, per aumentare le prestazioni di archiviazione del server è necessario riavviarlo.
  • L'archiviazione server può essere ridimensionata solo in incrementi di 2 volte. Per informazioni dettagliate, vedere Archiviazione .
  • Attualmente non è supportata la riduzione delle dimensioni di archiviazione del server. L'unico modo per eseguire questa operazione consiste nel eseguire il dump e ripristinarlo in una nuova istanza del server flessibile di Database di Azure per PostgreSQL.

Immagazzinamento

  • 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 95% o se la capacità disponibile è inferiore a 5 GiB (qualunque sia il valore maggiore), il sistema passa automaticamente il server alla modalità di sola lettura per evitare errori associati a situazioni di disco pieno. 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), un'istanza del 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 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. Un'istanza del server flessibile di Database di Azure per PostgreSQL usa lo spazio di tabella predefinito ereditato dal database modello. Non è sicuro specificare 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.
  • File di dati orfani e discrepanze di utilizzo del disco: in rari casi, PostgreSQL può lasciare i file di dati orfani su disco, ovvero file che non hanno più voci corrispondenti nel catalogo di sistema del database (che tiene traccia di tutte le tabelle e i dati). Ciò può verificarsi se una tabella viene creata e popolata all'interno di una transazione che non viene completata correttamente (ad esempio, a causa di un arresto anomalo o di un'interruzione del server), causando una mancata corrispondenza tra le dimensioni segnalate dal database e l'utilizzo effettivo del disco. Questo comportamento proviene dalla codebase della community postgreSQL e non è specifico di Azure. La community di PostgreSQL è consapevole del problema e sta esplorando i miglioramenti per la pulizia automatica nelle versioni future. Per altre informazioni, vedere: PostgreSQL: file orfani in PostgreSQL. Ciò può comportare un utilizzo imprevisto di disco o archiviazione elevato.
    • Procedura: confrontare le dimensioni segnalate dal database (usando query come SELECT pg_database_size('your_database')) con le metriche del portale di Azure per l'utilizzo effettivo del disco. Se si verifica una discrepanza significativa, i file orfani potrebbero essere la causa. In tal caso:
      • Eseguire VACUUM FULL sulle tabelle interessate per recuperare spazio. Nota: questa operazione è ad alto consumo di risorse, richiede un blocco della tabella e potrebbe necessitare di tempi di inattività.
      • In alternativa, utilizzare strumenti come le estensioni pg_repack o pg_squeeze per la riorganizzazione senza causare tempi di inattività, ma testare prima in un ambiente non di produzione.
      • Monitorare tramite le metriche del portale di Azure per le soglie di utilizzo del disco. Se il problema persiste o non si è certi, contattare il supporto tecnico di Azure per assistenza.
    • Procedura: Assicurarsi che le transazioni siano gestite correttamente nelle applicazioni per ridurre al minimo le operazioni incomplete. Monitorare regolarmente l'utilizzo del disco tramite le metriche del portale di Azure. L'aggiornamento alla versione più recente supportata di PostgreSQL può includere correzioni della community per i problemi correlati.

Rete

  • Attualmente non è supportato lo spostamento e l'uscita da una rete virtuale.
  • Attualmente non è supportata la combinazione dell'accesso pubblico con la distribuzione in una rete virtuale.
  • Le reti virtuali non supportano le regole del firewall. È 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à

  • Attualmente non è supportato lo spostamento manuale dei server in una zona di disponibilità diversa. 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

  • Un'istanza del server flessibile di Database di Azure per PostgreSQL supporta tutte le funzionalità del motore PostgreSQL, tra cui partizionamento, replica logica e wrapper di dati stranieri.
  • Un'istanza di Azure Database per PostgreSQL su server flessibile supporta tutte le contrib estensioni e altro ancora. Per altre informazioni, vedere Estensioni di PostgreSQL.
  • I server con burst attualmente non hanno accesso al pool di connessioni PgBouncer predefinito.

Operazioni di arresto/avvio

  • Dopo aver arrestato l'istanza del server flessibile di Database di Azure per PostgreSQL, tale istanza viene avviata automaticamente dopo sette 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 lo spazio di archiviazione di cui è stato effettuato il provisioning è 64 GB, il primo backup dello snapshot è 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 (PITR), il sistema crea il nuovo server con le stesse configurazioni di calcolo e archiviazione del server su cui si basa.
  • Il sistema ripristina i server di database nelle reti virtuali 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.
  • Non è supportato il ripristino in una sottoscrizione diversa. Come soluzione alternativa, è possibile ripristinare il server all'interno della stessa sottoscrizione e quindi eseguire la migrazione del server ripristinato a una sottoscrizione diversa.

Sicurezza

  • Postgres 14 e versioni successive disabilitano l'hash MD5 e le password native di Postgres vengono hashate utilizzando solo il metodo SCRAM-SHA-256.

Contenuti correlati

  • Last updated on