Použití sdružování připojení

Lakebase zahrnuje integrovaný nástroj pro sdružování připojení PgBouncer , který udržuje fond připojení k serveru a sdílí je napříč mnoha klientskými připojeními. Nástroj pro sdružování podporuje až 10 000 souběžných klientských připojení, takže je vhodný pro bezserverové funkce, webová rozhraní API a další aplikace, které otevírají mnoho krátkodobých připojení.

Sdružování připojení vyžaduje nativní ověřování hesla Postgres. Není k dispozici pro role OAuth.

Jak funguje sdružování připojení

Každé připojení Postgres využívá prostředky serveru, protože Postgres vytvoří pro každého klienta samostatný proces. S tím, jak se souběžná připojení zvětšují, můžou limit připojení serveru rychle vyčerpat.

Správce připojení se nachází mezi vaší aplikací a PostgreSQL. Klienti se připojují k nástroji pro sdružování a nástroj pro sdružování předává dotazy menšímu fondu skutečných připojení k serveru. Lakebase používá PgBouncer v transakčním režimu, takže spojení se serverem je vyhrazeno pouze po dobu jedné transakce a poté je vráceno zpět do poolu. To umožňuje mnoha klientům sdílet malý fond serverových připojení.

Fondy připojení

PgBouncer vytvoří samostatný fond pro každou kombinaci databází a uživatelů. Dva uživatelé, kteří se připojují ke stejné databázi, mají samostatné fondy. Velikost každého fondu je přibližně 90% limitu Postgres max_connections , který se liší podle velikosti výpočetních prostředků.

Když jsou všechna připojení ve fondu využita, nové požadavky klientů čekají ve frontě. Pokud se připojení k serveru do 2 minut nezpřístupní, klientovi je vyvolána chyba časového limitu.

Tento diagram znázorňuje, jak jsou vícečetná klientská připojení od různých uživatelů směrována přes samostatné pooly PgBounceru (jeden pro každou kombinaci uživatele a databáze), které sdílejí omezený počet skutečných připojení k PostgreSQL.

Omezení připojení

Tři omezení řídí sdružování připojení:

Limit	Hodnota	Co to řídí
Klientská připojení (max_client_conn)	10,000	Maximální počet připojení z aplikace k nástroji PgBouncer
Velikost fondu (default_pool_size)	~90 % z max_connections	Aktivní připojení k serveru na každou dvojici (uživatel, databáze)
Přímá připojení (max_connections)	Liší se podle velikosti výpočetních prostředků	Maximální počet přímých připojení Postgres

Limit přímého připojení závisí na velikosti výpočetních prostředků. Například výpočetní výkon 8 CU podporuje 1 678 přímých připojení a výpočetní výkon 16 CU podporuje 3 357. Úplný seznam najdete v části Specifikace výpočetních prostředků.

Limit 10 000 připojení klienta neznamená 10 000 souběžných výsledků dotazu. Představuje maximální počet klientských připojení PgBouncer přijímá. Počet souběžných aktivních transakcí je ohraničen velikostí fondu, což je přibližně 90% max_connections.

Povolení sdružování připojení

Předpoklady

• Projekt automatického škálování Lakebase musí být aktivní.
• V projektu musíte mít nativní roli hesla Postgres. Pokyny najdete v tématu Vytvoření nativní role hesla Postgres.
• Pokud chcete používat sdružování připojení s výpočetními instancemi jen pro čtení, musíte mít koncový bod vysoké dostupnosti s povoleným přístupem k výpočetním instancím jen pro čtení . Viz Vysoká dostupnost.

Steps

1. V aplikaci Lakebase přejděte do projektu a klikněte na Připojit.
2. Vyberte větev a výpočetní prostředky, ke které se chcete připojit.
3. V rozevíracím seznamu Role vyberte nativní roli hesla Postgres. Přepínač sdružování připojení je viditelný pouze v případech, kdy je vybrána role hesla. Je skrytý pro role OAuth.
4. Zapněte sdružování připojení.
5. Zkopírujte připojovací řetězec a použijte ho ve své aplikaci.

Formáty připojovacího řetězce

Připojovací řetězce nástroje pooler používají jiný název hostitele než přímá připojení k databázi. Název hostitele obsahuje za ID koncového bodu -pooler pro výpočetní prostředky pro čtení i zápis nebo -ro-pooler pro výpočetní prostředky jen pro čtení:

Typ výpočetních prostředků	Formát názvu hostitele	Kdy používat
Výpočetní prostředky pro čtení a zápis	<endpoint-id>-pooler.<region>.<cloud>.databricks.com	Veškerý provoz zápisu a čtení
Výpočetní kapacita pouze pro čtení	<endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com	Jen pro čtení. Vyžaduje koncový bod vysoké dostupnosti s povoleným přístupem pro čtení.

Oba používají port 5432.

Note

Zkopírujte připojovací řetězec pooleru přímo z dialogu Connect v aplikaci Lakebase a získejte správný hostname pro váš koncový bod, oblast a cloud.

Konfigurace nástroje PgBouncer

Lakebase spravuje PgBouncer s následujícím nastavením. Tato nastavení jsou opravená a nelze je přizpůsobit.

[pgbouncer]
pool_mode=transaction
max_client_conn=10000
default_pool_size=0.9 * max_connections
max_prepared_statements=1000
query_wait_timeout=120

Setting	Description
pool_mode=transaction	Serverová připojení se po každé transakci vracejí do fondu. Viz Režim transakce.
max_client_conn=10000	Maximální počet souběžných klientských připojení PgBouncer přijímá.
default_pool_size=0.9 * max_connections	Aktivní serverová připojení na každou dvojici (uživatel, databáze). Liší se podle velikosti výpočetních prostředků.
max_prepared_statements=1000	Umožňuje příkazy připravené na úrovni protokolu v režimu transakcí. Omezuje počet sledovaných příkazů na 1 000 pro jedno připojení klienta.
query_wait_timeout=120	Počet sekund, po které klient čeká na navázání spojení se serverem, než se zobrazí chyba časového limitu.

Režim transakcí

Režim transakcí zlepšuje efektivitu připojení, ale omezuje určité funkce Postgres, které vyžadují trvalé připojení k serveru. Při použití nástroje pro sdružování připojení nejsou k dispozici následující funkce:

• Příkazy připravené na úrovni SQL: PREPARE a DEALLOCATE příkazy nejsou podporovány v režimu transakcí. Připravené dotazy na úrovni driveru (interně používané v psycopg, node-postgres, JDBC a podobnými knihovnami) fungují správně díky podpoře PgBounceru na úrovni protokolu. Pokud se u JDBC zobrazí chyby související s připravenými příkazy, nastavte prepareThreshold=0 na vypnutí ukládání pojmenovaných připravených příkazů na straně serveru do mezipaměti.

• Nastavení na úrovni relace: SET Příkazy se neuchovávají napříč transakcemi, protože každá transakce může používat jiné připojení k serveru. Příklad:

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  Pokud chcete nastavení použít trvale, použijte ALTER ROLE místo toho:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Relací uchovávané dočasné tabulky: Dočasné tabulky, které přetrvávají po transakcích, nejsou k dispozici. Připojení vrácené do fondu může být přiřazeno jinému klientovi v další transakci.

• WITH HOLD kurzory: Kurzory deklarované s WITH HOLD vyžadují trvalé připojení a nejsou podporovány.

• Poradní zámky: PgBouncer nepodporuje poradní zámky. Poradní zámky vyžadují trvalé připojení k serveru, které není k dispozici v transakčním režimu.

• LISTEN/NOTIFY: Nepodporuje se. Pro aplikace, které vyžadují publikování/odběr zpráv, použijte přímé připojení (bez fondu).

• pg_dump a migrace schématu: Použijte přímé připojení pro pg_dump, migrace schématu a další nástroje, které spoléhají na stav na úrovni relace.

Note

Pro aplikace, které vyžadují funkce Postgresu na úrovni relace, použijte přímý připojovací řetězec z dialogu Connect bez zapnutí přepínače Connection pooling.