I våra tidigare inlägg i den här serien diskuterade vi fallet med anslutningspooling och introducerade PgBouncer. I det här inlägget kommer vi att diskutera dess mest populära alternativ – Pgpool-II.
Pgpool-II är den schweiziska armékniven för PostgreSQL-mellanvara. Den stöder hög tillgänglighet, ger automatiserad lastbalansering och har intelligensen att balansera last mellan masters och slavar så att skrivlaster alltid riktas mot masters, medan läslaster riktas till slavar. Pgpool-II tillhandahåller också logisk replikering. Även om dess användning och betydelse har minskat när de inbyggda replikeringsalternativen förbättrades på PostgreSQL-serversidan, är detta fortfarande ett värdefullt alternativ för äldre versioner av PostgreSQL. Utöver allt detta ger den också anslutningspoolning!
En överblick | ||||||
---|---|---|---|---|---|---|
|
Konfigurera Pgpool-II
Pgpool-II-binärfiler distribueras genom Pgpool-II:s arkiv – du kan läsa mer om installation i detta hjälpdokument. När den väl har installerats måste vi konfigurera Pgpool-II för att aktivera de tjänster vi vill ha och ansluta till PostgreSQL-servern. Du kan läsa mer om det här.
För att få en minimal sammanställningskonfiguration måste du tillhandahålla följande:
- Användarnamnet och det md5-krypterade lösenordet för användaren/användarna som ska ansluta till Pgpool-II – detta måste definieras i en separat fil, som enkelt kan genereras med hjälp av verktyget pg_md5.
- Gränssnitt/IP-adresser och portnummer att lyssna på för inkommande anslutningar – detta måste definieras i konfigurationsfilen.
- Värdnamnet för backend-servrarna [Mer än en server anges endast om vi vill använda replikering och/eller lastbalansering].
- De tjänster du vill aktivera. Som standard är anslutningspoolning på och andra tjänster är avstängda i konfigurationsfilen som är installerad med binärfilerna.
Och det är allt – vi är redo att börja! Även om de tillgängliga konfigurationerna med Pgpool-II kan vara mer skrämmande vid första anblicken, har folket bakom Pgpool-II verkligen gjort det enkelt för oss!
Så fungerar det
Pgpool-II har en mer involverad arkitektur än PgBouncer för att stödja alla funktioner den gör. Men i det här avsnittet kommer vi att begränsa oss till att beskriva hur anslutningspoolning fungerar.
Pgpool-II-förälderprocessen delar upp 32 underordnade processer som standard – dessa är tillgängliga för anslutning. Arkitekturen liknar PostgreSQL-servern:en process =en anslutning. Det klaffar också "pcp-processen" som används för administrativa uppgifter och utanför ramen för detta inlägg. De 32 barnen är nu redo att acceptera anslutningar. Precis som PgBouncer, emulerar dessa också en PostgreSQL-server – klienter kan ansluta med exakt samma anslutningssträng som de skulle göra med en vanlig PostgreSQL-server.
Kärnan dirigerar inkommande anslutningar till en av de underordnade processerna som har registrerats som lyssnare. Varken den huvudsakliga Pgpool-II-processen eller slutanvändarna har någon kontroll över vilken underordnad process som svarar på en inkommande begäran. Alla lediga barn kan hämta förfrågan. Om inga lediga barn hittas kommer anslutningsbegäran att köas på kärnan – detta kan göra att applikationer som pgbench hänger sig och väntar på klientanslutningar.
När ett inaktivt Pgpool-II-barn tar emot en anslutningsbegäran:
- Kontrollerar efter användarnamnet i lösenordsfilen. Om den inte hittas avvisar den anslutningen.
- Om användarnamnet hittas kontrollerar det det angivna lösenordet mot md5-hash som lagras i den här filen.
- När autentiseringen har lyckats kontrollerar den om den redan har en cachad anslutning för denna databas+användarkombination.
- Om den gör det returnerar den anslutningen till klienten. Om den inte gör det öppnar den en ny anslutning.
- Alla förfrågningar och svar passerar genom Pgpool-II medan den väntar på att klienten ska kopplas från.
- När klienten kopplar bort måste Pgpool-II bestämma om anslutningen ska cachelagras:
- Om den har en tom plats cachar den den.
- Om den inte har en tom plats (det vill säga att cachelagring av den här anslutningen skulle överskrida den tillåtna max_pool_size), kommer den att avgöra baserat på en intern algoritm.
- Om den bestämmer sig för att cachelagra anslutningen kommer den att köra den förkonfigurerade återställningsfrågan för att rensa upp alla sessionsdetaljer och göra den säker för återanvändning av en annan klient.
- Nu är den underordnade processen fri att ta upp fler kopplingar.
|
Vad gör inte Pgpool-II?
Tyvärr, för de som bara fokuserar på anslutningspooling, är det som Pgpool-II inte gör särskilt bra anslutningspooling, särskilt för ett litet antal klienter. Eftersom varje underordnad process har sin egen pool och det inte finns något sätt att kontrollera vilken klient som ansluter till vilken underordnad process, lämnas för mycket åt turen när det gäller att återanvända anslutningar.
Som du kan se har Pgpool och PgBouncer ganska olika styrkor – i vårt sista inlägg i serien kommer vi att göra ett head-to-head-test , och funktionsjämförelse! Håll utkik!
PostgreSQL Connection Pooling Series
|
---|