PgBouncer in Database di Azure per PostgreSQL

Database di Azure per PostgreSQL istanze del server flessibili offrono la possibilità di utilizzare PgBouncer come soluzione integrata per il pool di connessioni. PgBouncer è una funzionalità facoltativa che può essere abilitata per ogni server di database. È supportato nei livelli di calcolo per utilizzo generico e ottimizzato per la memoria sia nelle reti ad accesso pubblico che in reti ad accesso privato.

PgBouncer viene eseguito sulla stessa macchina virtuale (VM) del server di database per l'istanza di server flessibile di Database di Azure per PostgreSQL. Postgres usa un modello basato su processi per le connessioni, quindi la gestione di molte connessioni inattive comporta costi elevati. Postgres viene eseguito in vincoli di risorse quando il server esegue più di qualche migliaio di connessioni. Il vantaggio principale di PgBouncer consiste nel migliorare le connessioni inattive e le connessioni di breve durata nel server di database.

PgBouncer usa un modello leggero che utilizza operazioni I/O asincrone. Usa le connessioni Postgres solo quando necessario, ovvero quando si trova all'interno di una transazione aperta o quando una query è attiva. Questo modello consente l’aumento fino a 10.000 connessioni con sovraccarico ridotto.

La versione di PgBouncer distribuita in tutte le versioni principali supportate del motore, in Database di Azure per PostgreSQL, è 1.25.1. PgBouncer viene eseguito sulla porta 6432 nel server di database. È possibile modificare la configurazione della connessione di database dell'applicazione in modo da usare lo stesso nome host, ma impostare la porta su 6432 per iniziare a usare PgBouncer e beneficiare del ridimensionamento ottimizzato delle connessioni inattive.

PgBouncer in Database di Azure per PostgreSQL supporta l'autenticazione Microsoft Entra (Azure AD).

Abilitare e configurare PgBouncer

PgBouncer è particolarmente utile nelle applicazioni transazionali in cui la varianza frequente della connessione può ridurre le prestazioni. È abilitata per impostazione predefinita sulla porta 6432 ed è possibile connettersi usando lo stesso nome host del server PostgreSQL, ma con la porta 6432 anziché la porta predefinita 5432.

Per abilitare PgBouncer, passare al riquadro dei parametri Server nel portale di Azure, cercare PgBouncer e modificare l'impostazione pgbouncer.enabled su true. Non è necessario riavviare il server.

È possibile configurare le impostazioni di PgBouncer usando questi parametri.

Per altre informazioni sulle configurazioni di PgBouncer, vedere la documentazione pgbouncer.ini.

Vantaggi

Utilizzando la funzionalità integrata PgBouncer con l'istanza del server flessibile di Azure Database per PostgreSQL, si ottengono questi vantaggi:

• Comodità di una configurazione semplificata: poiché PgBouncer è integrato con l'istanza del server flessibile Database di Azure per PostgreSQL, non è necessaria un'installazione separata o una configurazione complessa. È possibile effettuare la configurazione direttamente dai parametri del server.

• Affidabilità di un servizio gestito: PgBouncer offre i vantaggi dei servizi gestiti di Azure. Ad esempio, Azure gestisce gli aggiornamenti di PgBouncer. Gli aggiornamenti automatici eliminano la necessità di manutenzione manuale e assicurano che PgBouncer rimanga aggiornato con le funzionalità e le patch di sicurezza più recenti.

• Support per vari tipi di connessione: PgBouncer in Database di Azure per PostgreSQL fornisce supporto per le connessioni pubbliche e private. È possibile usarlo per stabilire connessioni sicure su reti private o connettersi esternamente, a seconda dei requisiti specifici.

• Disponibilità elevata in scenari di failover: se un server di standby viene promosso a ruolo primario durante un failover, PgBouncer viene riavviato senza problemi nello standby appena promosso. Non è necessario apportare modifiche alla stringa di connessione dell'applicazione. Questa funzionalità consente di garantire disponibilità continua e ridurre al minimo le interruzioni del pool di connessioni dell'applicazione.

Monitoraggio di PgBouncer

Metriche

È possibile usare le metriche PgBouncer per monitorare le prestazioni del processo PgBouncer, inclusi i dettagli relativi alle connessioni attive, alle connessioni inattive, alle connessioni in pool totali e al numero di pool di connessioni. Ogni metrica viene generata a intervalli di 1 minuto e ha una cronologia che può arrivare fino a 93 giorni. I clienti possono configurare avvisi sulle metriche e accedere inoltre alle nuove dimensioni delle metriche per suddividere e filtrare i dati delle metriche in base al nome del database.

Come abilitare le metriche PgBouncer

• Per monitorare le metriche PgBouncer, assicurarsi che la funzionalità pgbouncer sia abilitata tramite il parametro pgbouncer.enabled, e che il parametro metrics.pgbouncer_diagnostics delle metriche sia abilitato.
• Questi parametri sono dinamici e non richiedono un riavvio dell'istanza.
• Le metriche PgBouncer sono disabilitate per impostazione predefinita.

Elenco delle metriche PgBouncer

Considerazioni sull'uso delle metriche PgBouncer

• Le metriche PgBouncer che usano la dimensione DatabaseName hanno un limite di 30 database.
• Nello SKU Burstable, il limite è di 10 database con la dimensione DatabaseName.
• Il limite della dimensione DatabaseName viene applicato alla colonna OID, che riflette l'ordine di creazione per il database.

Per altre informazioni, vedere Metriche PgBouncer.

Registrazioni

Azure Database per PostgreSQL server flessibile fornisce i log di PgBouncer per revisionare l'attività di pooling delle connessioni e risolvere i problemi come le interruzioni della connessione, gli errori di autenticazione o l'esaurimento del pool. I log pgBouncer includono dettagli quali errori di autenticazione, eventi del ciclo di vita della connessione, errori e modifiche dello stato del server. Questi dettagli sono utili per identificare i colli di bottiglia della connessione e le anomalie di comportamento.

Abilitazione dei log

Abilitare le impostazioni di diagnostica dei log per generare automaticamente i log PgBouncer. Log Analytics supporta due tipi di schema: Azure diagnostics e Resource-Specific. Per altre informazioni, vedere Schemi comuni e specifici del servizio per i log delle risorse di Azure.

• Schema diagnostico di Azure

  • I log vengono visualizzati nella AzureDiagnostics tabella.
  • Filtrare usando: Category == "PostgreSQLFlexPGBouncer".

• Schema specifico per la risorsa

  • I log vengono visualizzati nella PGSQLPgBouncer tabella.
  • È più semplice eseguire query in un formato strutturato.

Query KQL di esempio

Schema di diagnostica di Azure:

AzureDiagnostics
| where Category == "PostgreSQLFlexPGBouncer"
| where LogicalServerName_s =~ "your-server-name"
| order by TimeGenerated desc

Schema specifico per risorsa:

PGSQLPgBouncer
| where _ResourceId =~ "your-server-name"
| order by TimeGenerated desc

Console di amministrazione

PgBouncer fornisce anche un database interno denominato pgbouncer. Quando ci si connette a tale database, è possibile eseguire comandi SHOW che forniscono informazioni sullo stato corrente di PgBouncer.

Per connettersi al database pgbouncer:

1. Impostare il parametro pgBouncer.stats_users sul nome di un utente esistente (ad esempio, myUser) e applicare le modifiche.

2. Connettersi al database pgbouncer come utente e impostare la porta come 6432:

   psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=pgbouncer user=myUser password=<password> sslmode=require"
   

Dopo esserti connesso al database, usa i comandi SHOW per visualizzare le statistiche di PgBouncer.

• SHOW HELP: elencare tutti i comandi SHOW disponibili.
• SHOW POOLS: mostrare il numero di connessioni in ogni stato per ogni pool.
• SHOW DATABASES: mostrare i limiti correnti di connessione applicati per ogni database.
• SHOW STATS: mostrare statistiche sulle richieste e sul traffico per ogni database.

Per altre informazioni sui comandi PgBouncer SHOW, vedere Console di amministrazione.

Passaggio la propria applicazione all'uso di PgBouncer

Per iniziare a usare PgBouncer, seguire questi passaggi:

1. Connettersi al server di database, ma usare la porta 6432 anziché la normale porta 5432. Verificare che la connessione sia funzionante.

   psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=postgres user=myUser password=<password> sslmode=require"
   

2. Testare l'applicazione in un ambiente QA con PgBouncer per assicurarsi di non avere problemi di compatibilità. Il progetto PgBouncer fornisce una matrice di compatibilità ed è consigliabile usare pool di transazioni per la maggior parte degli utenti.

3. Modificare l'applicazione di produzione perché si connetta alla porta 6432 anziché alla porta 5432. Monitorare eventuali errori sul lato applicazione che potrebbero segnalare problemi di compatibilità.

PgBouncer in disponibilità elevata con ridondanza della zona

Nei server con ridondanza della zona e disponibilità elevata, il server primario esegue PgBouncer. È possibile connettersi a PgBouncer nel server primario sulla porta 6432. Dopo un failover, il sistema riavvia PgBouncer sul server secondario appena promosso, che ora è il server primario. Pertanto, la stringa di connessione dell'applicazione rimane invariata dopo il failover.

PgBouncer con cluster elastici

PgBouncer è disponibile anche per i cluster elastici. Ogni nodo in un cluster elastico ha una propria istanza di PgBouncer. Dopo averla abilitata, la porta 6432 instrada a PgBouncer nel nodo coordinatore del cluster elastico. Inoltre, la porta 8432 indirizza alle istanze di PgBouncer in esecuzione nei nodi di lavoro del cluster.

Limitazioni

• La funzionalità PgBouncer attualmente non supporta il livello di calcolo del server burstable. Se si modifica il livello di calcolo da Utilizzo generico o Ottimizzato per la memoria a con possibilità di burst, si perde la funzionalità PgBouncer integrata.
• Ogni volta che il server viene riavviato durante operazioni di scalabilità, failover a disponibilità elevata o un riavvio, il sistema riavvia anche PgBouncer e la macchina virtuale. È quindi necessario ristabilire le connessioni esistenti.
• Il portale non mostra tutti i parametri PgBouncer. Dopo aver abilitato PgBouncer e salvato i parametri, è necessario chiudere il riquadro Parametri server (ad esempio, selezionare Panoramica) e quindi tornare al riquadro Parametri server per visualizzare tutti i parametri.
• Non è possibile usare modalità pool di istruzioni insieme a istruzioni preparate. La versione corrente di PgBouncer aggiunge il supporto per istruzioni preparate in modalità di transazione. Questo supporto può essere abilitato e configurato tramite il parametro max_prepared_statements. L'impostazione di questo parametro sopra il valore predefinito 0 attiva il supporto per le istruzioni preparate. Questo supporto riguarda solo istruzioni preparate a livello di protocollo. Per la maggior parte dei linguaggi di programmazione, questo supporto significa che l'applicazione usa la funzione libpqPQprepare nel client, inviando comandi a livello di protocollo che PgBouncer può intercettare, anziché eseguire un comando SQL dinamico simile a PREPARE proc AS, che invia testo che PgBouncer non interpreta correttamente. Per verificare altre limitazioni della modalità pool scelta, vedere la documentazione di PgBouncer.
• Se si distribuisce PgBouncer in qualità di funzionalità, diventa un potenziale punto singolo di guasto. Se la funzionalità PgBouncer è inattiva, può interrompere l'intero pool di connessioni di database e causare tempi di inattività per l'applicazione. Per attenuare il singolo punto di errore, è possibile configurare più istanze di PgBouncer dietro un servizio di bilanciamento del carico per la disponibilità elevata nelle macchine virtuali Azure.
• PgBouncer è un'applicazione leggera che usa un'architettura a thread singolo. Questa progettazione è ideale per la maggior parte dei carichi di lavoro dell'applicazione. Nelle applicazioni che creano un numero elevato di connessioni di breve durata, tuttavia, questa progettazione potrebbe influire sulle prestazioni di PgBouncer e limitare la capacità di ridimensionare l'applicazione. Potrebbe essere necessario provare uno di questi approcci:
  • Distribuire il carico di connessione tra più istanze di PgBouncer su macchine virtuali Azure.
  • Prendere in considerazione soluzioni alternative, tra cui soluzioni multithreading come PgCat, nelle macchine virtuali Azure.

Per clienti che desiderano una gestione semplificata, disponibilità elevata integrata, connettività semplice con applicazioni in contenitori e la possibilità di usare i parametri di configurazione più diffusi, la funzionalità PgBouncer integrata è un’ottima scelta. Per i clienti che desiderano la scalabilità multithread, il controllo completo su tutti i parametri e un'esperienza di debug, configurare PgBouncer sulle macchine virtuali Azure potrebbe essere un'alternativa.

Contenuti correlati

• strategia di pooling delle connessioni per Database di Azure per PostgreSQL utilizzando PgBouncer
• Panoramica della rete per Database di Azure per PostgreSQL con accesso pubblico
• Rete con accesso privato per Database di Azure per PostgreSQL