PostgreSQL Connection Pooling:Del 3 – Pgpool-II

I vores tidligere indlæg i denne serie diskuterede vi sagen om forbindelsespooling og introducerede PgBouncer. I dette indlæg vil vi diskutere dets mest populære alternativ – Pgpool-II.

Pgpool-II er den schweiziske hærkniv for PostgreSQL-middleware. Den understøtter høj tilgængelighed, giver automatiseret belastningsbalancering og har intelligensen til at balancere belastning mellem mastere og slaver, så skrivebelastninger er altid rettet mod mastere, mens læsebelastninger er rettet til slaver. Pgpool-II giver også logisk replikering. Selvom dets brug og betydning er faldet, efterhånden som de indbyggede replikeringsmuligheder blev forbedret på PostgreSQL-serversiden, er dette stadig en værdifuld mulighed for ældre versioner af PostgreSQL. Oven i alt dette giver det også forbindelsespooling!

Et øjeblik

Opsætning af Pgpool-II Følg disse trin for at konfigurere Pgpool-II, aktivere de forbindelsespuljetjenester, du har brug for, og oprette forbindelse til din PostgreSQL-server. Læs nu Sådan virker det Tjek Pgpool-II-arkitekturen, der understøtter alle dens funktioner, og lær, hvordan forbindelsespooleren fungerer. Læs nu Hvad gør Pgpool-II ikke? Gennemgå begrænsningerne for Pgpool-II for at se, om det er den rigtige forbindelsespooler til din applikation. Læs nu

Opsætning af Pgpool-II

Pgpool-II binære filer distribueres gennem Pgpool-II's repositories – du kan læse mere om installation i dette hjælpedokument. Når det er installeret, skal vi konfigurere Pgpool-II til at aktivere de tjenester, vi ønsker, og oprette forbindelse til PostgreSQL-serveren. Du kan læse mere om det her.

For at få en minimal opsætning af pooling skal du angive følgende:

• Brugernavnet og md5-krypterede adgangskode for den eller de brugere, der vil oprette forbindelse til Pgpool-II – dette skal defineres i en separat fil, som nemt kan genereres ved hjælp af pg_md5 util.
• Interfaces/IP-adresser og portnummer til at lytte til for indgående forbindelser – dette skal defineres i konfigurationsfilen.
• Værtsnavnet på backend-serveren(e) [Mere end én server er kun angivet, hvis vi ønsker at bruge replikering og/eller belastningsbalancering].
• De tjenester, du ønsker at aktivere. Som standard er forbindelsespooling slået til, og andre tjenester er slået fra i den konfigurationsfil, der er installeret med binære filer.

Og det var det – vi er klar til at gå! Selvom de tilgængelige konfigurationer med Pgpool-II måske er mere skræmmende ved første øjekast, har folkene bag Pgpool-II virkelig gjort det nemt for os!

Sådan virker det

Pgpool-II har en mere involveret arkitektur end PgBouncer for at understøtte alle de funktioner, den gør. Men i dette afsnit vil vi begrænse os til at beskrive, hvordan forbindelsespooling fungerer.

Pgpool-II-forælderprocessen fordeler som standard 32 underordnede processer – disse er tilgængelige for tilslutning. Arkitekturen ligner PostgreSQL-serveren:én proces =én forbindelse. Det forgrener også 'pcp-processen', som bruges til administrative opgaver og uden for rammerne af dette indlæg. De 32 børn er nu klar til at tage imod forbindelser. Ligesom PgBouncer, emulerer disse også en PostgreSQL-server – klienter kan oprette forbindelse med nøjagtig den samme forbindelsesstreng, som de ville til en normal PostgreSQL-server.

Kernen dirigerer indgående forbindelser til en af ​​de underordnede processer, der er registreret som lyttere. Hverken Pgpool-II-hovedprocessen eller slutbrugerne har nogen kontrol over, hvilken underordnet proces, der svarer på en indgående anmodning. Ethvert ledigt barn kan afhente anmodningen. Hvis der ikke findes nogen inaktive børn, vil forbindelsesanmodningen blive sat i kø på kernesiden – dette kan få programmer som pgbench til at hænge og venter på klientforbindelser.

Når et inaktivt Pgpool-II-barn modtager en forbindelsesanmodning, vil det:

1. Søger efter brugernavnet i sin adgangskodefil. Hvis den ikke findes, afviser den forbindelsen.
2. Hvis brugernavnet er fundet, tjekker det den angivne adgangskode mod md5-hashen, der er gemt i denne fil.
3. Når godkendelsen lykkes, tjekker den, om den allerede har en cachet forbindelse til denne database+brugerkombination.
4. Hvis det gør det, returnerer det forbindelsen til klienten. Hvis den ikke gør det, åbner den en ny forbindelse.
5. Alle anmodninger og svar passerer gennem Pgpool-II, mens den venter på, at klienten afbryder forbindelsen.
6. Når klienten afbryder forbindelsen, skal Pgpool-II beslutte, om forbindelsen skal cache:
   • Hvis den har en tom plads, cacher den den.
   • Hvis den ikke har en tom plads (det vil sige, at cachelagring af denne forbindelse ville overskride den tilladte max_pool_size), vil den beslutte sig baseret på en intern algoritme.
7. Hvis den beslutter at cache forbindelsen, vil den køre den forudkonfigurerede nulstillingsforespørgsel for at rydde op i alle sessionsdetaljer og gøre den sikker til genbrug af en anden klient.
8. Nu er den underordnede proces fri til at opfange flere forbindelser.

Hvad gør Pgpool-II ikke?

Desværre, for dem, der kun fokuserer på forbindelsespooling, er det, Pgpool-II ikke gør særlig godt, forbindelsespooling, især for et lille antal klienter. Fordi hver underordnet proces har sin egen pulje, og der ikke er nogen måde at kontrollere, hvilken klient der forbinder til hvilken underordnet proces, er for meget overladt til heldet, når det kommer til at genbruge forbindelser.

Som du kan se, har Pgpool og PgBouncer ret forskellige styrker – i vores sidste indlæg i serien vil vi lave en head-to-head test , og funktionssammenligning! Hold dig opdateret!