Verwenden von Verbindungspooling

Lakebase enthält einen integrierten PgBouncer-Verbindungspooler , der einen Pool mit Serververbindungen verwaltet und über viele Clientverbindungen hinweg freigibt. Der Pooler unterstützt bis zu 10.000 gleichzeitige Clientverbindungen und eignet sich gut für serverlose Funktionen, Web-APIs und andere Anwendungen, die viele kurzlebige Verbindungen öffnen.

Für die Verbindungspooling ist eine systemeigene Postgres-Kennwortauthentifizierung erforderlich. Es ist nicht für OAuth-Rollen verfügbar.

Funktionsweise von Verbindungspooling

Jede Postgres-Verbindung verbraucht Serverressourcen, da Postgres für jeden Client einen separaten Prozess erstellt. Wenn gleichzeitige Verbindungen wachsen, können sie die Verbindungsgrenze des Servers schnell ausschöpfen.

Der Verbindungspooler befindet sich zwischen Ihrer Anwendung und Postgres. Clients stellen eine Verbindung mit dem Pooler her, und der Pooler leitet Abfragen an einen kleineren Pool tatsächlicher Serververbindungen weiter. Lakebase führt PgBouncer im Transaktionsmodus aus, sodass eine Serververbindung nur für die Dauer einer einzelnen Transaktion gehalten und dann an den Pool zurückgegeben wird. Auf diese Weise können viele Clients einen kleinen Pool mit Serververbindungen gemeinsam nutzen.

Verbindungspools

PgBouncer erstellt für jede Datenbank und Benutzerkombination einen separaten Pool. Zwei Benutzer, die eine Verbindung mit derselben Datenbank herstellen, erhalten unabhängige Pools. Die Größe jedes Pools beträgt ca. 90% der Postgres-Grenze max_connections , die je nach Berechnungsgröße variiert.

Wenn in einem Pool alle Verbindungen verwendet werden, warten neue Clientanforderungen in einer Warteschlange. Wenn eine Serververbindung innerhalb von 2 Minuten nicht verfügbar wird, empfängt der Client einen Timeoutfehler.

Das Diagramm zeigt, wie mehrere Clientverbindungen von verschiedenen Benutzern durch separate PgBouncer-Pools (eine pro Benutzer-/Datenbankkombination) geleitet werden, die eine begrenzte Anzahl tatsächlicher Postgres-Verbindungen gemeinsam nutzen.

Verbindungsbeschränkungen

Drei Grenzwerte regeln die Verbindungspooling:

Der Grenzwert für direkte Verbindungen hängt von der Berechnungsgröße ab. Beispielsweise unterstützt ein 8 CU-Compute 1.678 direkte Verbindungen und eine 16 CU-Berechnung unterstützt 3.357. Die vollständige Liste finden Sie unter Computespezifikationen.

Der Grenzwert für 10.000 Clientverbindung bedeutet nicht 10.000 gleichzeitige Abfrageergebnisse. Sie stellt die maximale Anzahl von Clientverbindungen dar, die PgBouncer akzeptiert. Die Anzahl der gleichzeitigen aktiven Transaktionen wird durch die Poolgröße begrenzt, die ungefähr 90 % von max_connections beträgt.

Aktivieren von Verbindungspooling

Voraussetzungen

• Ihr Lakebase Autoscaling-Projekt muss aktiv sein.
• Sie müssen über eine systemeigene Postgres-Kennwortrolle im Projekt verfügen. Anweisungen finden Sie unter Erstellen einer systemeigenen Postgres-Kennwortrolle.
• Um Verbindungspooling mit schreibgeschützten Computeinstanzen zu verwenden, müssen Sie einen Endpunkt für hohe Verfügbarkeit haben, bei dem Zugriff auf schreibgeschützte Computeinstanzen zulassen aktiviert ist. Siehe Hohe Verfügbarkeit.

Steps

1. Wechseln Sie in der Lakebase-App zu Ihrem Projekt, und klicken Sie auf "Verbinden".
2. Wählen Sie den Zweig und den Rechner aus, mit dem Sie eine Verbindung herstellen möchten.
3. Wählen Sie in der Dropdownliste "Rolle " eine systemeigene Postgres-Kennwortrolle aus. Der Verbindungspool-Switch ist nur sichtbar, wenn eine Kennwortrolle ausgewählt ist. Er ist für OAuth-Rollen ausgeblendet.
4. Aktivieren Verbindungspooling.
5. Kopieren Sie die Verbindungszeichenfolge, und verwenden Sie sie in Ihrer Anwendung.

Verbindungszeichenfolgenformate

Poolerverbindungszeichenfolgen verwenden einen anderen Hostnamen als direkte Datenbankverbindungen. Der Hostname enthält -pooler nach der Endpunkt-ID für die Berechnung mit Lese-/Schreibzugriff oder -ro-pooler für die schreibgeschützte Berechnung:

Beide verwenden Port 5432.

PgBouncer-Konfiguration

Lakebase verwaltet PgBouncer mit den folgenden Einstellungen. Diese Einstellungen sind festgelegt und können nicht angepasst werden.

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

Transaktionsmodus

Der Transaktionsmodus verbessert die Verbindungseffizienz, beschränkt jedoch bestimmte Postgres-Features, die eine dauerhafte Serververbindung erfordern. Die folgenden Features sind bei Verwendung des Verbindungspoolers nicht verfügbar:

• Vorbereitete Anweisungen auf SQL-Ebene: PREPARE und DEALLOCATE Anweisungen werden im Transaktionsmodus nicht unterstützt. Prepared Statements auf der Treiberebene (die intern von psycopg, node-postgres, JDBC und ähnlichen Bibliotheken verwendet werden) funktionieren dank der Unterstützung von PgBouncer auf Protokollebene korrekt. Wenn Fehler im Zusammenhang mit vorbereiteten Anweisungen angezeigt werden, sollten Sie prepareThreshold=0 festlegen, um das Zwischenspeichern von benannten serverseitigen vorbereiteten Anweisungen zu deaktivieren.

• Einstellungen auf Sitzungsebene: SET Befehle werden nicht über Transaktionen hinweg beibehalten, da jede Transaktion möglicherweise eine andere Serververbindung verwendet. Beispiel:

  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
  

  Um eine Einstellung dauerhaft anzuwenden, verwenden Sie ALTER ROLE stattdessen Folgendes:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Temporäre Tabellen im Sitzungs-Speicher: Temporäre Tabellen, die über Transaktionen hinweg bestehen, sind nicht verfügbar. Eine an den Pool zurückgegebene Verbindung kann einem anderen Client in der nächsten Transaktion zugewiesen werden.

• WITH HOLD Cursor: Cursor, die mit WITH HOLD eine dauerhafte Verbindung erfordern, werden nicht unterstützt.

• Empfehlungssperren: PgBouncer unterstützt keine Empfehlungssperren. Empfehlungssperren erfordern eine dauerhafte Serververbindung, die im Transaktionsmodus nicht verfügbar ist.

• LISTEN/NOTIFY: Nicht unterstützt. Verwenden Sie eine direkte (nicht poolierte) Verbindung für Anwendungen, für die pub/sub Messaging erforderlich ist.

• pg_dump und Schemamigrationen: Verwenden Sie eine direkte Verbindung für pg_dump, Schemamigrationen und andere Tools, die auf Sitzungsebene basieren.