db.dobo.sk

Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 10. Pgbouncer.

bez komentára

Pgbouncer je koneksn pooler, pretoze postgres nativne nema tuto vlastnost a mnoho koneksii do DB moze viest k vycerpaniu pamati, ale dosiahnutiu max_connections v Postgres konfe a odmietnutiu sluzby. Skvele zdovodnenie pouzitia pgbounceru so zaujimavou diskusiou je tu.

obecne

Postmaster obhospodaruje vsetky pokusy o pripojenie a pokial je uspesne, tak sa forkne na novy subproces, ktory sefuje spojeniu – az do doby, kedy ukonci spojenie aplikacia, alebo sam postmaster.

Pgbouncer ma vlastny pool na spojenia a sam si na zaklade nastavenia robi jeho management – spojenie vrati do svojho poolu a poskytuje ho dalej. Pri rotovani spojeni pouziva 3 typy poolovania:

  • session pooling (default) – udrzuje spojenie po celu session.
  • transaction pooling – po ukonceni transakcie ukonci spojenie a vrati ho do poolu
  • statement pooling – po ukonceni query ukonci spojenie

Inak je to standardna servisa, s hlavnym konfigurakom v /etc/pgbouncer.ini. Podporuje SSL/TLS.

jak to funguje

Z hladiska klienta naprosto transparentne – zada sa koneksn string na pgbouncer presne ako na postgres a pgbouncer to len “premosti” ma odpovedajuci postgres v konfigu. Priklad: psql -h PGBOUNCER_HOST -d DATABAZA -U user (normalny DB user, pgboncer to potom prekonekti, vysvetlenie nizsie)

useri, hesla a auth_user

Pri standardnom pripojovani sa clovek/aplikacia hlasi k Postgresu DB uctom/heslom. Tu je vsak vsunuta “vrstva pgbounceru”, ktory musi urobit autentikaciu sam. Je riesenie jednoduche a nepruzne (useri a ich hesla v userlist.txt) a zlozitejsie a pruzne: mapovanie pomocou auth_user.

Jednoduche riesenie je napisat user= a password= do pgbouncer.ini napriamo, alebo do userlist.txt. Nevyhodou samozrejme je, ze kazdy uzivatel tu musi mat svoj riadok a pri zmene hesla v DB sa to musi osefovat aj v konfigurakoch.

Zlozitejsie riesenie vyuziva funkcionalitu auth_user a auth_query. V tomto pripade sa user neporovnava s konfigurakom, ale pomocou auth_usera (preduzivatel) sa spusti auth_query, ktora sa dopta na uzivatela a jeho heslo priamo v postgrese. Pokial sa zhoduju, tak spojenie je nadviazane a uzivatel je pusteny do DB.

Zapis v pgbouncer.ini potom vypada asu takto>

db_spojenie = host=10.2.215.10 port=5432 dbname=NAZOV_DB max_db_connections=10 auth_user=app_pgbouncer pool_mode=session

a

 

 

píše: ďobo

July 20th, 2020 o 4:03 pm

chlievik: postgresql

okomentuj