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

PgBouncer 1.7 – „Farben variieren nach Auferstehung“

PgBouncer ist ein leichter Verbindungspooler für PostgreSQL. PgBouncer 1.7 wurde am 18. Dezember 2015 angekündigt. In diesem Blogbeitrag sprechen wir über die wichtigsten neuen Verbesserungen in PgBouncer.

Die buntesten Funktionen

  • PgBouncer 1.7 unterstützt TLS-Verbindungen und ich denke, das ist die größte Verbesserung der neuen Version. Sie verwendeten OpenSSL/LibreSSL-Bibliotheken als Backend-Implementierung der Funktion.
  • PgBouncer unterstützt jetzt Authentifizierung über TLS-Client-Zertifikat .

Lassen Sie uns in die Details der TLS-Einstellungen von PgBouncer eintauchen. Es gibt 14 Konfigurationsparameter im Zusammenhang mit der TLS-Einrichtung (clientseitige + serverseitige Einstellungen).

Um festzulegen, welcher TLS-Modus für Verbindungen von Clients verwendet werden soll, sollten wir client_tls_sslmode festlegen Parameter. TLS-Verbindungen sind standardmäßig deaktiviert. Wenn aktiviert, client_tls_key_file und client_tls_cert_file muss auch konfiguriert werden, um Schlüssel und Zertifikat einzurichten, die PgBouncer verwendet, um Client-Verbindungen zu akzeptieren.

Wir können ein Root-Zertifikat zuweisen, um Client-Zertifikate zu validieren, indem wir client_tls_ca_file festlegen Parameter, Standard ist nicht gesetzt.

Wir können angeben, welche TLS-Protokollversionen zulässig sind, indem wir client_tls_protocols festlegen Parameter, Standard ist all.

Ausführlichere clientseitige Einstellungen finden Sie unter client_tls_ciphers , client_tls_ecdhcurve und client_tls_dheparams Parameter.

Lassen Sie uns nun über die serverseitigen TLS-Konfigurationsparameter sprechen. Zuerst müssen wir den TLS-Modus deklarieren, der für Verbindungen zu PostgreSQL-Servern mit server_tls_sslmode verwendet werden soll Parameter. TLS-Verbindungen sind standardmäßig deaktiviert. Wir können CA-Server mit server_tls_ca_file zuweisen Parameter. Wenn wir PgBouncer einen privaten Schlüssel zuweisen möchten, um sich beim PostgreSQL-Server zu authentifizieren, können wir server_tls_key_file verwenden -Parameter können wir sogar ein Zertifikat für den privaten Schlüssel zuweisen, das der PostgreSQL-Server mit server_tls_cert_file validieren kann Parameter. Wie bei den clientseitigen TLS-Verbindungseinstellungen können wir mit server_tls_protocols angeben, welche TLS-Protokollversionen zulässig sind Parameter.

  • Nach der TLS-Unterstützung ist eine weitere wichtige neue Funktion die Unterstützung der Peer-Authentifizierung auf Unix-Sockets.
  • Als letztes wichtiges Feature dieser Version möchte ich die Unterstützung für eine Steuerdatei für den Host-basierten Zugriff wie pg_hba.conf in Postgres erwähnen. Dies ermöglicht die Konfiguration von TLS für Netzwerkverbindungen und Peer-Authentifizierung für lokale Verbindungen.

Wir können konfigurieren, wie Benutzer mit auth_type authentifiziert werden Parameter von PgBouncer. Alle Konfigurationsparameter sind in der Konfigurationsdatei pgbouncer.ini definiert. Sehen wir uns die Details von auth_type an Parameter.

auth_type Parameter kann einer der 6 unten aufgeführten Werte zugewiesen werden. Sehen wir uns die Erklärungen und die Verwendung dieser Werte an.

  • hba: Wenn wir den Parameter auth_type mit dem Wert hba setzen , sollten wir auth_hba_file setzen Parameter, um anzuzeigen, welche pg_hba.conf Datei wird als Konfiguration verwendet. Dadurch ermöglichen wir, dass der tatsächliche Authentifizierungstyp aus der auth_hba_file geladen wird. Das bedeutet, dass wir verschiedene Authentifizierungsmethoden für verschiedene Zugriffswege verwenden können. Verwenden Sie beispielsweise bei der Verbindung der Version 1.7 über Unix-Socket die Peer-Authentifizierungsmethode, gleichzeitig muss die Verbindung über TCP TLS verwenden. Bisher unterstützt das HBA-Dateiformat nicht alle Authentifizierungsmethoden von pg_hba.conf. Unterstützte Methoden sind:Trust, Reject, MD5, Password, Peer und Cert.
  • Zertifikat : Der Client muss sich über TLS verbinden Verbindung mit gültigem Client-Zertifikat. Der Benutzername wird dann von CommonName übernommen Feld aus dem Zertifikat.
  • md5 : Verwenden Sie die MD5-basierte Passwortprüfung. auth_file (der Name der Datei, aus der Benutzernamen und Passwörter geladen werden sollen ) kann sowohl MD5-verschlüsselte als auch Klartext-Passwörter enthalten. Dies ist die Standardauthentifizierungsmethode.
  • einfach : Das Klartext-Passwort wird über Kabel gesendet. Veraltet.
  • Vertrauen : Es findet keine Authentifizierung statt. Der Benutzername muss noch in auth_file vorhanden sein .
  • alle : Wie die Methode trust, aber der angegebene Benutzername wird ignoriert. Erfordert, dass alle Datenbanken so konfiguriert sind, dass sie sich als bestimmter Benutzer anmelden. Darüber hinaus ermöglicht die Konsolendatenbank jedem Benutzer, sich als Administrator anzumelden.

Andere Glanzfunktionen

In dieser Version wurden weitere Funktionen veröffentlicht. Sie können die PgBouncer-Änderungsprotokollseite besuchen oder die Liste unten auf andere Verbesserungen überprüfen:

  • Setzen Sie query_wait_timeout standardmäßig auf 120s. Dieser Parameter definiert die maximale Zeit, die Abfragen mit dem Warten auf die Ausführung verbringen dürfen. Wenn die Abfrage während dieser Zeit keinem Server zugewiesen wird, wird die Verbindung zum Client getrennt. Dies wird verwendet, um zu verhindern, dass nicht reagierende Server Verbindungen aufgreifen. Es hilft auch, wenn der Server ausgefallen ist oder die Datenbank aus irgendeinem Grund Verbindungen ablehnt. Wenn dies deaktiviert ist, werden Clients endlos in die Warteschlange gestellt. Der aktuelle Standardwert (0) verursacht eine unendliche Warteschlange, was nicht sinnvoll ist. Wenn der Client mit der Version 1.7 eine ausstehende Abfrage hat und nicht der Serververbindung zugewiesen wurde, wird die Clientverbindung standardmäßig nach 120 Sekunden getrennt.
  • Deaktivieren Sie server_reset_query_always standardmäßig. Jetzt wird die Reset-Abfrage nur in Pools verwendet, die sich im Sitzungsmodus befinden.
  • Erhöhen Sie pkt_buf bis 4096 Byte. Verbessert die Leistung mit TLS . Das Verhalten ist wahrscheinlich lastspezifisch, aber es sollte sicher sein, da seit v1.2 die Paketpuffer von Verbindungen getrennt und träge vom Pool verwendet werden.
  • Unterstützung für Pipelining-Anzahl erwartet ReadyForQuery Pakete. Dadurch wird vermieden, dass der Server zu früh freigegeben wird. Behebt #52.
  • Verbesserter sbuf_loopcnt Logik – Socket wird garantiert erneut verarbeitet, auch wenn es kein Ereignis von Socket gibt. Erforderlich für TLS da es über eine eigene Pufferung verfügt.
  • Systemtests anpassen, um mit modernen BSD zu arbeiten und MacOS . (Eric Radman )
  • Entfernen Sie Krypta Authentifizierung Es ist veraltet und wird von PostgreSQL seit 8.4 nicht mehr unterstützt .
  • Beheben Sie das einfache “–with-cares” Konfigurationsoption – ohne Argument war es kaputt.

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.

Sie können PgBouncer über die Download-Seite herunterladen und sofort verwenden!

Weitere Informationen zu PgBouncer finden Sie in meinem vorherigen Blogbeitrag zu PgBouncer.

Viel Spaß beim Lesen!