Pokud jde o sdružování připojení ve světě PostgreSQL, PgBouncer je pravděpodobně nejoblíbenější možností. Je to velmi jednoduchý nástroj, který dělá přesně jednu věc – sedí mezi databází a klienty a mluví s protokolem PostgreSQL, emuluje server PostgreSQL. Klient se připojuje k PgBouncer přesně stejnou syntaxí, jakou by použil při přímém připojení k PostgreSQL – PgBouncer je v podstatě neviditelný.
PgBouncer je podporován téměř každým dodavatelem PostgreSQL DBaaS a široce používán v celé komunitě. V tomto příspěvku na blogu vysvětlíme, jak PgBouncer funguje, jaké jsou výhody a nevýhody jeho používání a jak nastavit pooler připojení. Pokud se chcete dozvědět více o sdružování připojení obecně nebo se ptáte, zda je to správné pro vaše nasazení, podívejte se na náš příspěvek PostgreSQL Connection Pooling:Část 1 – Klady a zápory.
PostgreSQL Connection Pooling Series
|
---|
Jak PgBouncer funguje?
Když PgBouncer obdrží připojení klienta, nejprve provede ověření jménem serveru PostgreSQL. PgBouncer podporuje všechny autentizační mechanismy, které PostgreSQL server podporuje, včetně konfigurace přístupu založeného na hostiteli (poznámka:nemůžeme směrovat replikační připojení přes PgBouncer). Pokud je zadáno heslo, lze ověření provést dvěma způsoby:
- PgBouncer nejprve zkontroluje soubor userslist.txt – tento soubor specifikuje sadu (uživatelské jméno, šifrovaná hesla md5) n-tic. Pokud uživatelské jméno v tomto souboru existuje, je heslo porovnáno s danou hodnotou. Není vytvořeno žádné připojení k serveru PostgreSQL.
- Pokud je nastaveno průchozí ověřování a uživatel není nalezen v souboru userslist.txt, PgBouncer hledá auth_query. Připojí se k PostgreSQL jako předdefinovaný uživatel (jehož heslo musí být přítomno v souboru userslist.txt) a provede auth-query, aby nalezl heslo uživatele a přiřadil jej k zadané hodnotě.
Po úspěšném ověření:
- PgBouncer zkontroluje připojení uložené v mezipaměti se stejnou kombinací uživatelského jména a databáze.
- Pokud je nalezeno připojení uložené v mezipaměti, vrátí připojení klientovi.
- Pokud není připojení uložené v mezipaměti nalezeno, vytvoří se nové připojení za předpokladu, že vytvoření nového připojení ne:
- Zvyšte počet připojení na> pool_size
- Zvyšte počet připojení z klienta na> max_client_connections
- Zvyšte počet připojení k databázi na> max_db_connections
- Zvyšte počet připojení od uživatele na> max_user_connections
- Všechny tyto hodnoty lze definovat v nastavení PgBouncer.
- Pokud by vytvoření nového připojení porušilo některé z nastavení, PgBouncer zařadí připojení do fronty, dokud nebude možné vytvořit nové, s výjimkou případů, kdy porušuje omezení max_client_connections.
Poznámka – Načasování kroků po autentizaci se mírně liší v závislosti na režimu PgBouncer. V režimu sdružování transakcí nebo výpisů se kroky po autentizaci provádějí pouze tehdy, když klient začne provádět transakci/výpis. Více o režimech sdružování diskutujeme níže. - Pokud poruší omezení max_client_connections, připojení přeruší.
Na základě sdružování režimu, PgBouncer čeká na příležitost vrátit spojení zpět do databáze:
- V režimu sdružování relací je připojení vráceno do fondu pouze tehdy, když klient relaci zavře.
- V režimu sdružování transakcí je připojení vráceno do fondu pouze tehdy, když klient dokončí transakci (obvykle se provede buď vrácení nebo potvrzení). V důsledku toho nejsou v tomto režimu podporovány funkce založené na relacích. Neexistuje žádná záruka, že dvě transakce provedené na stejném klientském připojení PgBouncer poběží na stejném připojení k serveru PgBouncer.
- V režimu sdružování příkazů je připojení vráceno do fondu ihned po provedení příkazu. Zde je automatické potvrzení vždy zapnuto.
Před vrácením připojení zpět do databáze spustí PgBouncer resetovací dotaz, aby z něj odstranil všechny informace o relaci – díky tomu je sdílení připojení mezi klienty bezpečné. Tento dotaz je možné nakonfigurovat na základě potřeb aplikace.
Režim sdružování transakcí se používá nejčastěji, i když režim sdružování relací může být užitečný pro konkrétní úlohy. Více o PgBouncer si můžete přečíst na jejich Wiki stránce.
PostgreSQL Connection Pooling:Část 2 – PgBouncerClick To TweetProč zvolit PgBouncer?
Je mnoho důvodů, proč je PgBouncer nejoblíbenější volbou, pokud jde o sdružování připojení v PostgreSQL. Zde jsou některé z nejlepších funkcí a výhod, které PgBouncer nabízí:
- Režimy sdružování – Tím, že dává uživatelům pravomoc rozhodnout, kdy se připojení vrátí do fondu, je PgBouncer schopen podporovat širokou škálu případů použití. A protože toto nastavení je na úrovni fondu, můžete použít transakční režim (lepší výkon) pro vaše obvyklá databázová připojení a režim relace pouze v případě, že požadujete funkce, jako jsou připravené příkazy!
- Snadné nastavení a použití – PgBouncer je jedním z nejjednodušších sdružovačů připojení PostgreSQL, který lze nastavit ihned po vybalení a také nevyžaduje žádné změny kódu na straně klienta.
- Přechodové ověření – PgBouncer je jedním z mála „middlewarových“ sdružovačů připojení, které mohou bezpečně ověřit uživatele, aniž by měli přístup k jeho heslům (v prostém textu nebo v zašifrované podobě). Díky tomu je PgBouncer bezpečnější a mnohem jednodušší na údržbu – PgBouncer nemusíte aktualizovat pokaždé, když si uživatel aktualizuje heslo.
- Nízká hmotnost – Jedná se o jediný proces a všechny příkazy od klienta a odpovědi ze serveru procházejí PgBouncerem bez jakéhokoli zpracování. Nemusí tedy ‚vidět‘ celý obsah najednou, a proto si zachovává velmi malou paměť.
- Škálovatelnost a výkon – Jak podrobněji probereme v poslední části našeho seriálu, PgBouncer dokáže výrazně zlepšit transakce za sekundu, které váš PostgreSQL server podporuje, a velmi dobře se škáluje na velmi velký počet klientů.
Co PgBouncer nedělá?
PgBouncer, přestože je skvělým nástrojem pro sdílení připojení, nepodporuje automatické vyrovnávání zátěže ani vysokou dostupnost. Doporučuje použít jiné běžné linuxové nástroje jako HAProxy k vytvoření architektury, která tyto funkce podporuje.
Podívejte se na ukázkovou architekturu PostgreSQL pro čtení s vyvážením zatížení níže:
Poznámka – Hlavní uzel (že všichni tito podřízení by se replikovalo z) není v diagramu zobrazeno.
Jak nastavit PgBouncer
Pokud máte ScaleGrid PostgreSQL nasazení, můžete PgBouncer nastavit několika kliknutími. Přejděte do zobrazení podrobností vašeho clusteru PostgreSQL a klikněte na ikonu PgBouncer. Jakmile vyberete „Enable PgBouncer“, zobrazí se vám možnosti konfigurace pro přizpůsobení režimu sdružování a velikosti fondu – můžete přijmout výchozí hodnoty (nebojte se, můžete je kdykoli změnit bez prostojů) a klikněte na Povolit!
A je to! Můžete jít.
Pokud máte nasazení jiné než ScaleGrid, PgBouncer je distribuován jako součást úložiště PostgreSQL a lze jej nainstalovat pomocí příslušných správců balíčků. Pro podrobnější pokyny nebo pro sestavení ze zdroje můžete postupovat podle pokynů z jejich blogu.
Po instalaci vyžaduje PgBouncer pouze nastavení několika konfiguračních parametrů, aby se mohl spustit:
- Seznam (uživatelské jméno, šifrované heslo md5) pro ověřování klientů nebo nastavení průchozího ověřování pro bezpečnější nasazení.
- Rozhraní/IP:porty pro naslouchání příchozím připojením.
- Definice fondu. „Pool“ je název, který klienti používají jako název databáze při připojování k PgBouncer – lze jej namapovat na úplný připojovací řetězec (hostitel, port, název databáze a uživatel). Nejjednodušší definice je ve tvaru:
* = host=
Tím se vytvoří dynamické fondy pro každou kombinaci dbname+uživatel a připojí se k definovanému hostiteli pomocí portu, dbname a uživatelského jména poskytnutého uživatelem.
A je to! S PgBouncer můžete být v provozu velmi rychle. Existuje však mnohem více nastavení, která musí být vyladěna pro jakoukoli produkční distribuci – ta jsou nad rámec tohoto blogového příspěvku, ale více si o nich můžete přečíst v tomto přehledu konfigurací PgBouncer.
PgBouncer však není jedinou možností pro sdružování připojení PostgreSQL – v našem dalším příspěvku se budeme zabývat Pgpool-II, což je pravděpodobně hlavní konkurent PgBouncer. Zůstaňte naladěni na náš čtvrtý příspěvek v této čtyřdílné sérii, kde porovnáváme PgBouncer vs. Pgpool-II.