Pooling di connessioni PostgreSQL:parte 3 – Pgpool-II

Nei nostri post precedenti di questa serie, abbiamo discusso il caso del pool di connessioni e introdotto PgBouncer. In questo post, discuteremo della sua alternativa più popolare:Pgpool-II.

Pgpool-II è il coltellino svizzero del middleware PostgreSQL. Supporta l'alta disponibilità, fornisce il bilanciamento del carico automatizzato e ha l'intelligenza per bilanciare il carico tra master e slave, in modo che i carichi di scrittura siano sempre diretti ai master, mentre i carichi di lettura siano diretti agli slave. Pgpool-II fornisce anche la replica logica. Sebbene il suo utilizzo e importanza siano diminuiti con il miglioramento delle opzioni di replica integrate sul lato server di PostgreSQL, questa rimane ancora un'opzione preziosa per le versioni precedenti di PostgreSQL. Inoltre, fornisce anche il pool di connessioni!

A colpo d'occhio

Configurazione di Pgpool-II Segui questi passaggi per configurare Pgpool-II, abilitare i servizi di pool di connessione di cui hai bisogno e connetterti al tuo server PostgreSQL. Leggi ora Come funziona Scopri l'architettura Pgpool-II che supporta tutte le sue funzionalità e scopri come funziona il pool di connessioni. Leggi ora Cosa non fa Pgpool-II? Esamina le limitazioni di Pgpool-II per vedere se è il pool di connessioni giusto per la tua applicazione. Leggi ora

Configurazione di Pgpool-II

I binari di Pgpool-II sono distribuiti tramite i repository di Pgpool-II:puoi leggere di più sull'installazione in questo documento di aiuto. Una volta installato, dobbiamo configurare Pgpool-II per abilitare i servizi che vogliamo e connetterci al server PostgreSQL. Puoi leggere di più a riguardo qui.

Per ottenere una configurazione minima del pool, devi fornire quanto segue:

• Il nome utente e la password crittografata md5 degli utenti che si collegheranno a Pgpool-II:devono essere definiti in un file separato, che può essere facilmente generato utilizzando l'utility pg_md5.
• Interfacce/indirizzi IP e numero di porta da ascoltare per le connessioni in entrata:questo deve essere definito nel file di configurazione.
• Il nome host del o dei server back-end [Viene specificato più di un server solo se si desidera utilizzare la replica e/o il bilanciamento del carico].
• I servizi che desideri abilitare. Per impostazione predefinita, il pool di connessioni è attivo e altri servizi sono disattivati ​​nel file di configurazione installato con i binari.

E questo è tutto:siamo pronti per partire! Mentre le configurazioni disponibili con Pgpool-II potrebbero essere più scoraggianti a prima vista, le persone dietro Pgpool-II ci hanno davvero semplificato la vita!

Come funziona

Pgpool-II ha un'architettura più complessa di PgBouncer per supportare tutte le funzionalità che fa. Tuttavia, in questa sezione, ci limiteremo a descrivere come funziona il pool di connessioni.

Il processo padre Pgpool-II esegue il fork di 32 processi figlio per impostazione predefinita:questi sono disponibili per la connessione. L'architettura è simile al server PostgreSQL:un processo =una connessione. Crea anche il "processo pcp" che viene utilizzato per attività amministrative e oltre lo scopo di questo post. I 32 bambini sono ora pronti ad accettare connessioni. Come PgBouncer, anche questi emulano un server PostgreSQL:i client possono connettersi con la stessa stringa di connessione identica a un normale server PostgreSQL.

Il kernel dirige le connessioni in entrata a uno dei processi figlio che si sono registrati come listener. Né il processo principale Pgpool-II né gli utenti finali hanno alcun controllo su quale processo figlio risponde a una richiesta in arrivo. Qualsiasi bambino inattivo può ritirare la richiesta. Se non vengono trovati elementi secondari inattivi, la richiesta di connessione verrà accodata sul lato kernel:questo può causare il blocco di applicazioni come pgbench, in attesa di connessioni client.

Una volta che un figlio Pgpool-II inattivo riceve una richiesta di connessione, esso:

1. Cerca il nome utente nel suo file di password. Se non viene trovato, rifiuta la connessione.
2. Se viene trovato il nome utente, controlla la password fornita rispetto all'hash md5 memorizzato in questo file.
3. Una volta che l'autenticazione riesce, controlla se ha già una connessione cache per questa combinazione database+utente.
4. Se lo fa, restituisce la connessione al client. In caso contrario, si apre una nuova connessione.
5. Tutte le richieste e le risposte passano attraverso Pgpool-II mentre attende la disconnessione del client.
6. Una volta disconnesso il client, Pgpool-II deve decidere se memorizzare nella cache la connessione:
   • Se ha uno slot vuoto, lo memorizza nella cache.
   • Se non ha uno slot vuoto (ovvero, la memorizzazione nella cache di questa connessione supererebbe la max_pool_size consentita), deciderà in base a un algoritmo interno.
7. Se decide di memorizzare nella cache la connessione, eseguirà la query di ripristino preconfigurata per ripulire tutti i dettagli della sessione e renderla sicura per il riutilizzo da parte di un altro client.
8. Ora il processo figlio è libero di acquisire più connessioni.

Cosa non fa Pgpool-II?

Purtroppo, per coloro che si concentrano solo sul pool di connessioni, ciò che Pgpool-II non fa molto bene è il pool di connessioni, specialmente per un numero limitato di client. Poiché ogni processo figlio ha il proprio pool e non c'è modo di controllare quale client si connette a quale processo figlio, troppo viene lasciato alla fortuna quando si tratta di riutilizzare le connessioni.

Come puoi vedere, Pgpool e PgBouncer hanno punti di forza piuttosto diversi:nel nostro post finale della serie, faremo un test testa a testa e confronto delle funzionalità! Resta sintonizzato!