PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Pool di connessioni PostgreSQL:parte 2 – PgBouncer

Quando si tratta di pool di connessioni nel mondo PostgreSQL, PgBouncer è probabilmente l'opzione più popolare. È un'utilità molto semplice che fa esattamente una cosa:si trova tra il database e i client e parla il protocollo PostgreSQL, emulando un server PostgreSQL. Un client si connette a PgBouncer con la stessa identica sintassi che userebbe quando si connette direttamente a PostgreSQL:PgBouncer è essenzialmente invisibile.

PgBouncer è supportato da quasi tutti i fornitori di PostgreSQL DBaaS e ampiamente utilizzato nella comunità. In questo post del blog, spiegheremo come funziona PgBouncer, i pro ei contro del suo utilizzo e come configurare il pool di connessioni. Se desideri saperne di più sul pool di connessioni in generale o se ti chiedi se è adatto alla tua distribuzione, dai un'occhiata al nostro post sul pool di connessioni PostgreSQL:parte 1 – Pro e contro.

Serie di pool di connessioni PostgreSQL

  • Parte 1 – Pro e contro
  • Parte 2 – PgBouncer
  • Parte 3 – Pgpool-II
  • Parte 4 – PgBouncer vs. Pgpool-II

Come funziona PgBouncer?

Quando PgBouncer riceve una connessione client, esegue prima l'autenticazione per conto del server PostgreSQL. PgBouncer supporta tutti i meccanismi di autenticazione supportati dal server PostgreSQL, inclusa una configurazione di accesso basato su host (nota:non possiamo instradare le connessioni di replica tramite PgBouncer). Se viene fornita una password, l'autenticazione può essere eseguita in due modi:

  1. PgBouncer controlla prima il file userslist.txt – questo file specifica un insieme di tuple (nome utente, password crittografate md5). Se il nome utente esiste in questo file, la password viene confrontata con il valore specificato. Non viene stabilita alcuna connessione al server PostgreSQL.
  2. Se l'autenticazione passthrough è impostata e l'utente non viene trovato nel file userslist.txt, PgBouncer cerca una auth_query. Si collega a PostgreSQL come utente predefinito (la cui password deve essere presente nel file userslist.txt) ed esegue la query di autenticazione per trovare la password dell'utente e abbinarla al valore fornito.

Una volta completata l'autenticazione:

  1. PgBouncer verifica la presenza di una connessione nella cache, con la stessa combinazione nome utente+database.
  2. Se viene trovata una connessione memorizzata nella cache, restituisce la connessione al client.
  3. Se non viene trovata una connessione memorizzata nella cache, viene creata una nuova connessione, a condizione che la creazione di una nuova connessione non:
    • Aumenta il numero di connessioni a> pool_size
    • Aumenta il numero di connessioni dal client a> max_client_connections
    • Aumenta il numero di connessioni al database a> max_db_connections
    • Aumenta il numero di connessioni dall'utente a> max_user_connections
  4. Tutti questi valori possono essere definiti nelle impostazioni di PgBouncer.
  5. Se la creazione di una nuova connessione viola una qualsiasi delle impostazioni, PgBouncer mette in coda la connessione fino a quando non è possibile crearne una nuova, a meno che non violi la restrizione max_client_connections.
    Nota – I tempi dei passaggi post-autenticazione differiscono leggermente in base alla modalità PgBouncer. In modalità di pool di transazioni o istruzioni, i passaggi successivi all'autenticazione vengono eseguiti solo quando il client inizia a eseguire una transazione/un estratto conto. Discutiamo di più sulle modalità di raggruppamento di seguito.
  6. Se viola la restrizione max_client_connections, interrompe la connessione.

Basato sul pooling modalità, PgBouncer attende un'opportunità per riportare la connessione al database:

  • In modalità pool di sessioni, una connessione viene restituita al pool solo quando un client chiude la sessione.
  • Nella modalità di pool di transazioni, una connessione viene restituita al pool solo quando un client completa una transazione (in genere viene eseguito un rollback o un commit). Di conseguenza, le funzionalità basate sulla sessione non sono supportate in questa modalità. Non vi è alcuna garanzia che due transazioni eseguite sulla stessa connessione client PgBouncer vengano eseguite sulla stessa connessione server PgBouncer.
  • In modalità pool di istruzioni, viene restituita una connessione al pool non appena viene eseguita un'istruzione. Qui, l'autocommit è sempre attivo.

Prima di restituire la connessione al database, PgBouncer esegue una query di ripristino per rimuovere tutte le informazioni sulla sessione:ciò rende sicura la condivisione delle connessioni tra i client. È possibile configurare questa query in base alle esigenze dell'applicazione.

La modalità di pool di transazioni viene utilizzata più spesso, sebbene la modalità di pool di sessioni possa essere utile per carichi di lavoro particolari. Puoi leggere di più su PgBouncer sulla loro pagina Wiki.

Pool di connessioni PostgreSQL:parte 2 – PgBouncerClick To Tweet

Perché scegliere PgBouncer?

Ci sono molte ragioni per cui PgBouncer è la scelta più popolare quando si tratta di pool di connessioni in PostgreSQL. Ecco alcune delle migliori caratteristiche e vantaggi offerti da PgBouncer:

  • Modalità di pooling – Dando agli utenti il ​​potere di decidere quando una connessione viene restituita al pool, PgBouncer è in grado di supportare una vasta gamma di casi d'uso. E, poiché questa configurazione è a livello di pool, puoi utilizzare la modalità transazione (prestazioni migliori) per le tue normali connessioni al database e la modalità sessione solo quando hai bisogno di funzionalità come le istruzioni preparate!
  • Installazione e utilizzo semplici – PgBouncer è uno dei pool di connessioni PostgreSQL più facili da configurare e non richiede modifiche al codice lato client.
  • Autenticazione pass-through – PgBouncer è uno dei pochi pool di connessioni "middleware" in grado di autenticare in modo sicuro un utente senza avere accesso alle sue password (in chiaro o in forma crittografata). Ciò rende PgBouncer più sicuro e molto più facile da mantenere:non è necessario aggiornare PgBouncer ogni volta che un utente aggiorna la propria password.
  • Leggero – È un processo unico e tutti i comandi dal client e le risposte dal server passano attraverso PgBouncer senza alcuna elaborazione. Quindi, non ha bisogno di "vedere" l'intero contenuto in una volta e, quindi, mantiene un footprint di memoria molto ridotto.
  • Scalabilità e prestazioni – Come discuteremo più dettagliatamente nella parte finale della nostra serie, PgBouncer può migliorare significativamente le transazioni al secondo che il tuo server PostgreSQL può supportare e si adatta molto bene a un numero molto elevato di client.

Cosa non fa PgBouncer?

PgBouncer, sebbene sia un ottimo pool di connessioni, non supporta il bilanciamento del carico automatizzato o l'elevata disponibilità. Consiglia di utilizzare altri strumenti Linux comuni come HAProxy per creare un'architettura che supporti queste funzionalità.

Dai un'occhiata all'architettura PostgreSQL di esempio per le letture con bilanciamento del carico di seguito:

Nota – Il nodo master (che tutti questi slave verrebbe replicato da) non è mostrato nel diagramma.

Come configurare PgBouncer

Se hai una distribuzione ScaleGrid PostgreSQL, puoi configurare PgBouncer in pochi clic. Vai alla visualizzazione dei dettagli del tuo cluster PostgreSQL e fai clic sull'icona PgBouncer. Dopo aver selezionato "Abilita PgBouncer", ti verranno presentate le opzioni di configurazione per personalizzare la modalità di pooling e le dimensioni del pool:puoi accettare le impostazioni predefinite (non preoccuparti, puoi modificarle in qualsiasi momento senza tempi di inattività) e fare clic su Abilita!

E il gioco è fatto! Sei a posto.

Se hai una distribuzione non ScaleGrid, PgBouncer è distribuito come parte del repository PostgreSQL e può essere installato utilizzando i rispettivi gestori di pacchetti. Per istruzioni più dettagliate o per creare dal sorgente, puoi seguire le istruzioni dal loro blog.

Una volta installato, PgBouncer richiede solo di impostare alcuni parametri di configurazione per entrare in funzione:

  1. Un elenco di (nome utente, password crittografata md5) per autenticare i client o una configurazione di autenticazione passthrough per una distribuzione più sicura.
  2. Interfacce/IP:porte per ascoltare le connessioni in entrata.
  3. Definizioni pool. Un "pool" è un nome che i client utilizzano come nome del database durante la connessione a PgBouncer:può essere mappato su una stringa di connessione completa (host, porta, dbname e utente). La definizione più semplice è nella forma:
    * = host=
    Ciò creerà pool dinamici per ciascuna combinazione dbname+utente e si connetterà all'host definito utilizzando la porta, dbname e nome utente forniti dall'utente.

E questo è tutto! Puoi essere subito operativo con PgBouncer. Tuttavia, ci sono molte altre impostazioni che devono essere ottimizzate per qualsiasi distribuzione di produzione:queste vanno oltre lo scopo di questo post del blog, ma puoi leggere di più su di esse in questa panoramica delle configurazioni di PgBouncer.

PgBouncer, tuttavia, non è l'unica opzione per il pool di connessioni PostgreSQL:nel nostro prossimo post parleremo di Pgpool-II, che è probabilmente il principale concorrente di PgBouncer. Resta sintonizzato per il nostro quarto post in questa serie in quattro parti in cui confrontiamo PgBouncer e Pgpool-II.