Nachfolgend finden Sie einen Auszug aus unserem Whitepaper „PostgreSQL Management and Automation with ClusterControl“, das kostenlos heruntergeladen werden kann.
Überarbeitungshinweis:Denken Sie daran, dass die in diesem Blog verwendeten Begriffe Master-Slave synonym zu den von PostgreSQL verwendeten Master-Standby-Begriffen sind. Wir verwenden Master-Slave, um die Parallelität mit anderen Technologien aufrechtzuerhalten.
Für die HA-Konfiguration können wir mehrere Architekturen haben, aber die grundlegenden wären Master-Slave- und Master-Master-Architekturen. Datenbankserver können zusammenarbeiten, damit ein zweiter Server schnell übernehmen kann, wenn der primäre Server ausfällt (hohe Verfügbarkeit). ) oder um mehreren Computern zu ermöglichen, dieselben Daten bereitzustellen (Load Balancing).
PostgreSQL-Master-Slave-Architekturen
Diese Architekturen ermöglichen es uns, eine Master-Datenbank mit einem oder mehreren Standby-Servern zu unterhalten, die bereit sind, den Betrieb zu übernehmen, wenn der primäre Server ausfällt. Diese Standby-Datenbanken bleiben mit dem Master synchronisiert (oder nahezu synchronisiert).
Die Replikation zwischen dem Master und den Slaves kann über SQL-Anweisungen (logische Standbys) oder über Änderungen der internen Datenstruktur (physikalische Standbys) erfolgen. PostgreSQL verwendet einen Strom von WAL-Einträgen (Write-Ahead Log), um die Standby-Datenbanken synchron zu halten. Fällt der Hauptserver aus, enthält der Standby fast alle Daten des Hauptservers und kann schnell zum neuen Master-Datenbankserver gemacht werden. Dies kann synchron oder asynchron erfolgen und kann nur für den gesamten Datenbankserver durchgeführt werden.
Das Einrichten der Streaming-Replikation ist eine Aufgabe, bei der einige Schritte sorgfältig befolgt werden müssen. Diese Schritte und weitere Hintergrundinformationen zu diesem Thema finden Sie unter:Become a PostgreSQL DBA – How to Setup Streaming Replication for High Availability.
Ab Version 10 enthält PostgreSQL die Option zum Einrichten der logischen Replikation.
Die logische Replikation ermöglicht es einem Datenbankserver, einen Strom von Datenänderungen an einen anderen Server zu senden. Die logische PostgreSQL-Replikation erstellt einen Strom logischer Datenänderungen aus der WAL. Die logische Replikation ermöglicht die Replikation der Datenänderungen einzelner Tabellen. Es erfordert nicht, dass ein bestimmter Server als Master oder Replikat bestimmt wird, sondern ermöglicht den Datenfluss in mehrere Richtungen.
Weitere Informationen zur logischen Replikation finden Sie im Blog:An Overview of Logical Replication in PostgreSQL.
Um eine hohe Verfügbarkeit effektiv zu gewährleisten, reicht eine Master-Slave-Architektur nicht aus. Wir müssen auch eine automatische Form von Failover aktivieren, damit wir bei einem Ausfall die kleinstmögliche Verzögerung bei der Wiederaufnahme der normalen Funktionalität haben können. PostgreSQL enthält keinen automatischen Failover-Mechanismus, um Fehler in der Master-Datenbank zu identifizieren und den Salve zu benachrichtigen, den Besitz zu übernehmen, so dass dies ein wenig Arbeit auf der Seite des DBA erfordern wird. Sie sollten an einem Skript arbeiten, das den Befehl pg_ctl promote enthält, der den Slave zu einem neuen Master befördert. Es gibt auch einige Tools von Drittanbietern für diese Automatisierung. Viele solcher Tools sind vorhanden und gut in die Betriebssystemfunktionen integriert, die für ein erfolgreiches Failover erforderlich sind, z. B. IP-Adressmigration.
Nach einem Failover müssen Sie Ihre Anwendung entsprechend ändern, damit sie mit dem neuen Master funktioniert. Sie werden auch nur einen Server haben, der arbeitet, also muss die Master-Slave-Architektur neu erstellt werden, damit wir zu der gleichen normalen Situation zurückkehren, die wir vor dem Problem hatten.
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunterPostgreSQL-Master-Master-Architekturen
Diese Architektur bietet eine Möglichkeit, die Auswirkungen eines Fehlers in einem der Knoten zu minimieren, da der andere Knoten den gesamten Datenverkehr übernehmen kann, was möglicherweise die Leistung geringfügig beeinträchtigt, aber niemals die Funktionalität verliert. Es wird auch verwendet, um (und vielleicht ist dies ein noch interessanterer Punkt) horizontale Skalierbarkeit (Scale-out) zu erreichen, im Gegensatz zum Konzept der vertikalen Skalierbarkeit, bei der wir einem Server mehr Ressourcen hinzufügen (Scale-up).
Für die Implementierung dieser Architektur müssen Sie externe Tools verwenden, da diese Funktion (noch) nicht nativ von PostgreSQL unterstützt wird.
Sie müssen bei der Auswahl einer Lösung zur Implementierung von Master-Master sehr vorsichtig sein, da es viele verschiedene Produkte gibt. Viele von ihnen sind immer noch „grün“, mit wenigen ernsthaften Benutzern oder Erfolgsfällen. Einige andere Projekte wurden dagegen aufgegeben, da es keine aktiven Betreuer gibt.
Weitere Informationen zu den verfügbaren Tools finden Sie unter:Blog:Top PG Clustering HA Solutions for PostgreSQL.
Load Balancing und Connection Pooling
Es gibt mehrere Load-Balancer-Tools, mit denen Sie den Datenverkehr Ihrer Anwendung verwalten können, um das Beste aus Ihrer Datenbankarchitektur herauszuholen. Auf die gleiche Weise gibt es einige andere, die Ihnen helfen können, die Art und Weise zu verwalten, wie die Anwendung eine Verbindung zur Datenbank herstellt, indem sie diese Verbindungen in einem Pool zusammenfassen und sie zwischen verschiedenen Anforderungen wiederverwenden.
Es gibt einige Produkte, die für beide Zwecke verwendet werden, wie das bekannte pgpool, und einige andere, die sich nur auf eine dieser Funktionen konzentrieren, wie pgbouncer (Verbindungspooling) und HAProxy (verwendet für den Lastausgleich).
