PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Was ist neu in PgBouncer 1.6

PgBouncer ist ein leichter Verbindungspooler für PostgreSQL.

PgBouncer 1.6 wurde am 1. August 2015 angekündigt. In diesem Blogbeitrag sprechen wir über die wichtigsten neuen Verbesserungen in PgBouncer.

Neue Hauptfunktionen von PgBouncer

Benutzerkennwort-Hash aus der Postgres-Datenbank laden

PgBouncer ermöglicht jetzt das Laden des Benutzerpassworts aus der Datenbank mit zwei Konfigurationsparametern, die auth_user sind und auth_query .

  • auth_user
    Wenn auth_user festgelegt ist, wird jeder Benutzer, der nicht in auth_file angegeben ist, von pg_shadow in der Datenbank mit auth_user abgefragt. Das Passwort von Auth_user wird aus auth_file genommen. Dieser Parameter kann auch pro Datenbank eingestellt werden.

  • auth_query
    Mit diesem Parameter können wir eine SQL-Abfrage schreiben, um das Passwort des Benutzers aus der Datenbank zu laden. Es läuft unter auth_user. Siehe die Standardabfrage unten:

    SELECT usename, passwd FROM pg_shadow WHERE usename=$1

Der Pooling-Modus kann sowohl pro Datenbank als auch pro Benutzer konfiguriert werden

Mit dieser Funktion können sich Clients jetzt unabhängig vom Haupt-Pooling-Modus mit verschiedenen Datenbanken mit einem der 3 unten beschriebenen Pooling-Modi verbinden. Dies gilt auch für Benutzer. Wenn der Pooling-Modus beispielsweise Sitzungspooling ist, kann ein bestimmter Benutzer für die Verwendung von Transaktionspooling konfiguriert werden. Dies gibt uns Flexibilität auf Datenbank- und Benutzerebene, um geeignetere Pooling-Optionen anzuwenden.

PgBouncer bietet 3 Verbindungspooling-Modi:

  • Sitzungspooling
     Während der Lebensdauer einer Clientverbindung wird dem Client eine vorhandene Serververbindung zugewiesen, und nachdem der Client die Verbindung getrennt hat, wird die zugewiesene Serververbindung wieder dem Verbindungspool hinzugefügt.
  • Transaktionspooling
     In diesem Modus wird einem verbundenen Client eine Serververbindung nicht sofort zugewiesen, sondern erst während einer Transaktion. Sobald die Transaktion beendet ist, wird die Verbindung wieder in den Pool gestellt.
  • Zusammenfassung von Anweisungen
     Dies ähnelt dem Transaktionspooling, ist jedoch aggressiver. Ein Back-End wird immer dann zugewiesen, wenn eine Abfrage mit einer einzelnen Anweisung ausgegeben wird. Wenn die Anweisung beendet ist, wird die Verbindung wieder in den Pool gestellt.

Verbindungslimits pro Datenbank und Benutzer:max_db_connections und max_user_connections

Mit dieser Funktion können wir jetzt auch Verbindungslimits pro Datenbank/Benutzerebene mit den zwei neuen Parametern steuern, die max_db_connections sind und max_user_connections .

  • max_db_connections
    Dieser Parameter erlaubt nicht mehr als die angegebenen Verbindungen pro Datenbank (unabhängig vom Pool – d. h. Benutzer).
    Der Standardwert dieses Parameters ist unbegrenzt.
  • max_user_connections
    Dieser Parameter erlaubt nicht mehr als die angegebenen Verbindungen pro Benutzer (unabhängig vom Pool – d. h. Benutzer).

Befehle DISABLE/ENABLE hinzufügen, um neue Verbindungen zu verhindern

Mit dieser Funktion hat PgBouncer ENABLE/DISABLE db; Befehle, um neue Verbindungen zu verhindern.

  • DB DEAKTIVIEREN;
    Dieser Befehl lehnt alle neuen Client-Verbindungen in der angegebenen Datenbank ab.
  • DB AKTIVIEREN;
    Dieser Befehl erlaubt neue Client-Verbindungen nach einem vorherigen DISABLE Befehl.

Neues bevorzugtes DNS-Backend:c-ares

c-ares ist das einzige DNS-Backend, das alle interessanten Funktionen unterstützt:/etc/hosts mit Aktualisierung, SOA-Lookup, große Antworten (über TCP/EDNS+UDP), IPv6. Es ist jetzt das bevorzugte Back-End und wird wahrscheinlich das einzige sein Backend in Zukunft.

Konfigurationsdateien haben die Anweisung „%include FILENAME“, damit die Konfiguration in mehrere Dateien aufgeteilt werden kann

Mit dieser Funktion unterstützt PgBouncer das Einfügen von Konfigurationsdateien in andere Konfigurationsdateien.

Mit anderen Worten, die PgBouncer-Konfigurationsdatei kann Include-Direktiven enthalten, die eine andere zu lesende und zu verarbeitende Konfigurationsdatei angeben. Dadurch kann eine große Konfigurationsdatei in kleinere und besser zu verwaltende Dateien aufgeteilt werden. Die Include-Direktiven sehen so aus:

%include filename

Wenn der Dateiname kein absoluter Pfad ist, wird er relativ zum aktuellen Arbeitsverzeichnis genommen.

In dieser Version wurden weitere Funktionen veröffentlicht. Weitere Verbesserungen finden Sie auf der PgBouncer-Änderungsprotokollseite oder in der folgenden Liste:

  • Zeige remote_pid in CLIENTS/SERVER ANZEIGEN. Verfügbar für Clients, die sich über Unix-Sockets und sowohl TCP- als auch Unix-Socket-Server verbinden. Im Falle eines TCP-Servers wird die PID aus dem Abbruchschlüssel genommen.
  • Fügen Sie einen separaten Konfigurationsparameter (dns_nxdomain_ttl) hinzu, um negatives DNS-Caching zu steuern.
  • Fügen Sie die IP-Adresse und den Port des Client-Hosts zu Anwendungsname hinzu. Dies wird durch einen Konfigurationsparameter application_name_add_host aktiviert, der standardmäßig auf „off“ gesetzt ist.

Was ist PgBouncer?

PgBouncer ist ein Dienstprogramm zum Verwalten von Clientverbindungen zur PostgreSQL-Datenbank. Kurz gesagt, es unterhält einen Verbindungspool zum PostgreSQL-Server und verwendet diese vorhandenen Verbindungen wieder. Dies kann zwar nützlich sein, um den Overhead der Clientverbindung zu reduzieren, ermöglicht aber auch die Begrenzung der maximalen Anzahl offener Verbindungen zum Datenbankserver. Es kann auch für Traffic-Shaping verwendet werden, z. B. um Verbindungen zu einer oder mehreren Datenbanken auf verschiedene Datenbankserver umzuleiten. Darüber hinaus kann PgBouncer zur Verwaltung der Sicherheit auf Benutzer- und sogar auf Datenbankebene verwendet werden.

Sehen Sie sich das Diagramm unten an, das die PgBouncer-Architektur auf visuellere Weise darstellt.

In diesem speziellen Beispiel sind Clientanwendungen mit separaten PgBouncer-Instanzen verbunden, wo sie stattdessen direkt mit PostgreSQL-Datenbankservern verbunden wären. Die Datenbankserver „DB-Server 1“ und „DB-Server 2“ können unabhängige PostgreSQL-Instanzen oder Teil eines Clusters mit unterschiedlichen Rollen sein (z. B. Master/Replikat oder Write-Master/Backup-Master usw.).

Jede PgBouncer-Instanz verwaltet einen Verbindungspool mit einer Reihe offener Verbindungen zu PostgreSQL-Servern. Wie aus dem Beispiel ersichtlich ist, ermöglicht PgBouncers das Erstellen von Pools mit Verbindungen zu verschiedenen Datenbanken und sogar Verbindungen zu verschiedenen Datenbankservern.

Weitere Informationen

Sie können die Hauptwebsite von PgBouncer besuchen: http://pgbouncer.github.io/

Sie haben eine nette FAQ-Seite: http://pgbouncer.github.io/faq.html

Sie können sich das Github-Repository des Projekts ansehen: http://github.com/pgbouncer/pgbouncer