PostgreSQL Connection Pooling:Part 3 – Pgpool-II

In onze eerdere berichten in deze serie bespraken we de case voor pooling van verbindingen en introduceerden we PgBouncer. In dit bericht zullen we het meest populaire alternatief bespreken:Pgpool-II.

Pgpool-II is het Zwitserse zakmes van PostgreSQL-middleware. Het ondersteunt hoge beschikbaarheid, biedt geautomatiseerde taakverdeling en heeft de intelligentie om de belasting tussen masters en slaves te verdelen, zodat schrijfbelastingen altijd naar masters worden gestuurd, terwijl leesbelastingen naar slaves worden gestuurd. Pgpool-II biedt ook logische replicatie. Hoewel het gebruik en belang ervan is afgenomen naarmate de ingebouwde replicatie-opties verbeterden aan de PostgreSQL-serverzijde, blijft dit nog steeds een waardevolle optie voor oudere versies van PostgreSQL. Bovendien biedt het ook pooling van verbindingen!

In één oogopslag

Pgpool-II instellen Volg deze stappen om Pgpool-II in te stellen, de verbindingspoolservices in te schakelen die u nodig hebt en verbinding te maken met uw PostgreSQL-server. Lees nu Hoe het werkt Bekijk de Pgpool-II-architectuur die alle functies ondersteunt en leer hoe de verbindingspooler werkt. Lees nu Wat doet Pgpool-II niet? Bekijk de beperkingen van Pgpool-II om te zien of dit de juiste verbindingspooler is voor uw toepassing. Lees nu

Pgpool-II instellen

Pgpool-II binaries worden gedistribueerd via de repository's van Pgpool-II - u kunt meer lezen over installatie in dit helpdocument. Eenmaal geïnstalleerd, moeten we Pgpool-II configureren om de gewenste services in te schakelen en verbinding te maken met de PostgreSQL-server. Je kunt er hier meer over lezen.

Om een ​​minimale pooling-configuratie te krijgen, moet u het volgende verstrekken:

• De gebruikersnaam en het md5-gecodeerde wachtwoord van de gebruiker(s) die verbinding maken met Pgpool-II - dit moet worden gedefinieerd in een apart bestand, dat eenvoudig kan worden gegenereerd met behulp van het pg_md5-hulpprogramma.
• Interfaces/IP-adressen en poortnummer om naar te luisteren voor inkomende verbindingen - dit moet worden gedefinieerd in het configuratiebestand.
• De hostnaam van de backend-server(s) [Er wordt alleen meer dan één server opgegeven als we replicatie en/of taakverdeling willen gebruiken].
• De services die u wilt inschakelen. Standaard is pooling van verbindingen ingeschakeld en zijn andere services uitgeschakeld in het configuratiebestand dat met de binaire bestanden is geïnstalleerd.

En dat is alles - we zijn klaar om te gaan! Hoewel de configuraties die beschikbaar zijn met Pgpool-II op het eerste gezicht misschien meer ontmoedigend zijn, hebben de mensen achter Pgpool-II het ons echt gemakkelijk gemaakt!

Hoe het werkt

Pgpool-II heeft een meer betrokken architectuur dan PgBouncer om alle functies die het doet te ondersteunen. In deze sectie zullen we ons echter beperken tot een beschrijving van hoe pooling van verbindingen werkt.

Het Pgpool-II bovenliggende proces verdeelt standaard 32 onderliggende processen – deze zijn beschikbaar voor verbinding. De architectuur is vergelijkbaar met de PostgreSQL-server:één proces =één verbinding. Het splitst ook het 'pcp-proces' dat wordt gebruikt voor administratieve taken, en valt buiten het bestek van dit bericht. De 32 kinderen zijn nu klaar om connecties te accepteren. Net als PgBouncer emuleren deze ook een PostgreSQL-server - clients kunnen verbinding maken met exact dezelfde verbindingsreeks als met een normale PostgreSQL-server.

De kernel stuurt inkomende verbindingen naar een van de onderliggende processen die als listeners zijn geregistreerd. Noch het hoofdproces van Pgpool-II, noch de eindgebruikers hebben enige controle over welk kindproces op een binnenkomend verzoek reageert. Elk inactief kind kan het verzoek ophalen. Als er geen inactieve kinderen worden gevonden, wordt het verbindingsverzoek in de wachtrij geplaatst aan de kernelzijde - dit kan ertoe leiden dat toepassingen zoals pgbench vastlopen, wachtend op clientverbindingen.

Zodra een inactief Pgpool-II-kind een verbindingsverzoek ontvangt, zal het:

1. Controleert op de gebruikersnaam in het wachtwoordbestand. Als het niet wordt gevonden, wordt de verbinding geweigerd.
2. Als de gebruikersnaam wordt gevonden, wordt het opgegeven wachtwoord vergeleken met de md5-hash die in dit bestand is opgeslagen.
3. Zodra de authenticatie is gelukt, wordt gecontroleerd of er al een verbinding in de cache is voor deze combinatie van database en gebruiker.
4. Als dit het geval is, wordt de verbinding naar de client geretourneerd. Als dit niet het geval is, wordt er een nieuwe verbinding geopend.
5. Alle verzoeken en reacties gaan door Pgpool-II terwijl het wacht tot de client de verbinding verbreekt.
6. Zodra de client de verbinding verbreekt, moet Pgpool-II beslissen of de verbinding in de cache moet worden opgeslagen:
   • Als het een leeg slot heeft, wordt het in de cache opgeslagen.
   • Als het geen leeg slot heeft (dat wil zeggen dat het cachen van deze verbinding de toegestane max_pool_size zou overschrijden), beslist het op basis van een intern algoritme.
7. Als het besluit om de verbinding in de cache op te slaan, zal het de vooraf geconfigureerde reset-query uitvoeren om alle sessiedetails op te schonen en het veilig te maken voor hergebruik door een andere client.
8. Het onderliggende proces is nu vrij om meer verbindingen op te pikken.

Wat doet Pgpool-II niet?

Helaas, voor degenen die zich alleen richten op pooling van verbindingen, is wat Pgpool-II niet zo goed doet het poolen van verbindingen, vooral voor een klein aantal klanten. Omdat elk kindproces zijn eigen pool heeft en er geen manier is om te bepalen welke client verbinding maakt met welk kindproces, wordt er teveel aan geluk overgelaten als het gaat om het hergebruik van verbindingen.

Zoals je kunt zien, hebben Pgpool en PgBouncer nogal verschillende sterke punten - in ons laatste bericht van de serie zullen we een onderlinge test doen , en functievergelijking! Blijf op de hoogte!