PostgreSQL-Replikation: Ein umfassender Leitfaden

Wie Ihnen jeder Websitebesitzer bestätigen wird, können Datenverluste und Ausfallzeiten, selbst in minimalen Dosen, katastrophale Folgen haben. Sie können jederzeit auf Unvorbereitete treffen, was zu verringerter Produktivität, Zugänglichkeit und Produktvertrauen führt.

Um die Integrität Ihrer Website zu schützen, ist es wichtig, Sicherheitsvorkehrungen gegen mögliche Ausfallzeiten oder Datenverluste zu treffen.

Hier kommt die Datenreplikation ins Spiel.
Wie jeder Websitebesitzer Ihnen sagen wird, können Datenverlust und Ausfallzeiten selbst in minimalen Dosen katastrophal sein. Enter, Datenreplikation Click to Tweet
Die Datenreplikation ist ein automatisierter Backup-Prozess, bei dem Ihre Daten zur sicheren Aufbewahrung wiederholt aus der Hauptdatenbank an einen anderen, entfernten Standort kopiert werden. Es ist eine integrale Technologie für jede Website oder App, auf der ein Datenbankserver ausgeführt wird. Sie können die replizierte Datenbank auch nutzen, um schreibgeschütztes SQL zu verarbeiten, sodass mehr Prozesse innerhalb des Systems ausgeführt werden können.

Das Einrichten der Replikation zwischen zwei Datenbanken bietet Fehlertoleranz gegen unerwartete Pannen. Es gilt als die beste Strategie, um bei Katastrophen eine hohe Verfügbarkeit zu erreichen.

In diesem Artikel tauchen wir in die verschiedenen Strategien ein, die von Backend-Entwicklern für eine nahtlose PostgreSQL-Replikation implementiert werden können.

Was ist PostgreSQL-Replikation?

PostgreSQL-Replikation ist definiert als der Vorgang des Kopierens von Daten von einem PostgreSQL-Datenbankserver auf einen anderen Server. Der Quelldatenbankserver wird auch als „primärer“ Server bezeichnet, während der Datenbankserver, der die kopierten Daten empfängt, als „Replikatserver“ bezeichnet wird.

Die PostgreSQL-Datenbank folgt einem unkomplizierten Replikationsmodell, bei dem alle Schreibvorgänge an einen primären Knoten gehen. Der primäre Knoten kann diese Änderungen dann anwenden und sie an sekundäre Knoten senden.

Was ist automatisches Failover?

Sobald die physische Streaming-Replikation in PostgreSQL konfiguriert wurde, kann ein Failover stattfinden, wenn der primäre Server der Datenbank ausfällt. Failover wird verwendet, um den Wiederherstellungsprozess zu definieren, der eine Weile dauern kann, da er keine integrierten Tools zum Auswerten von Serverausfällen bietet.

Sie müssen für Failover nicht auf PostgreSQL angewiesen sein. Es gibt dedizierte Tools, die ein automatisches Failover und automatisches Umschalten in den Standby-Modus ermöglichen, wodurch die Ausfallzeit der Datenbank verkürzt wird.

Indem Sie die Failover-Replikation einrichten, garantieren Sie eine hohe Verfügbarkeit, indem Sie sicherstellen, dass Standbys verfügbar sind, falls der primäre Server jemals zusammenbricht.

Vorteile der Verwendung der PostgreSQL-Replikation

Hier sind einige wichtige Vorteile der Nutzung der PostgreSQL-Replikation:

• Datenmigration : Sie können die PostgreSQL-Replikation für die Datenmigration entweder durch eine Änderung der Datenbankserverhardware oder durch Systembereitstellung nutzen.
• Fehlertoleranz : Wenn der Primärserver ausfällt, kann der Standby-Server als Server agieren, da die enthaltenen Daten für Primär- und Standby-Server dieselben sind.
• Leistung der Online-Transaktionsverarbeitung (OLTP) : Sie können die Transaktionsverarbeitungszeit und die Abfragezeit eines OLTP-Systems verbessern, indem Sie die Berichtsabfragelast entfernen. Die Transaktionsverarbeitungszeit ist die Dauer, die für die Ausführung einer bestimmten Abfrage benötigt wird, bevor eine Transaktion abgeschlossen ist.
• Parallele Systemtests : Beim Upgrade eines neuen Systems müssen Sie sicherstellen, dass das System mit den vorhandenen Daten gut funktioniert, daher müssen Sie es vor der Bereitstellung mit einer Kopie der Produktionsdatenbank testen.

Funktionsweise der PostgreSQL-Replikation

Im Allgemeinen glauben die Leute, wenn Sie sich mit einer primären und sekundären Architektur beschäftigen, gibt es nur eine Möglichkeit, Backups und Replikation einzurichten, aber PostgreSQL-Bereitstellungen folgen einem der folgenden drei Ansätze:

1. Replikation auf Volume-Ebene, um auf der Speicherebene vom primären zum sekundären Knoten zu replizieren, gefolgt von der Sicherung auf Blob/S3-Speicher.
2. PostgreSQL-Streaming-Replikation , um Daten vom primären auf den sekundären Knoten zu replizieren, gefolgt von der Sicherung auf Blob/S3-Speicher.
3. Inkrementelle Backups vom primären Knoten auf S3 erstellen, während ein neuer sekundärer Knoten von S3 rekonstruiert wird. Wenn sich der sekundäre Knoten in der Nähe des primären Knotens befindet, können Sie mit dem Streaming vom primären Knoten beginnen.

Ansatz 1: Streamen

Die PostgreSQL-Streaming-Replikation, auch bekannt als WAL-Replikation, kann nahtlos nach der Installation von PostgreSQL auf allen Servern eingerichtet werden. Dieser Replikationsansatz basiert auf dem Verschieben der WAL-Dateien von der primären in die Zieldatenbank.

Sie können die PostgreSQL-Streaming-Replikation implementieren, indem Sie eine Primär-Sekundär-Konfiguration verwenden. Der primäre Server ist die Hauptinstanz, die die primäre Datenbank und alle ihre Operationen verarbeitet. Der sekundäre Server fungiert als ergänzende Instanz und führt alle Änderungen an der primären Datenbank auf sich selbst aus und erzeugt dabei eine identische Kopie. Der Primärserver ist der Lese-/Schreibserver, während der Sekundärserver lediglich schreibgeschützt ist.

Für diesen Ansatz müssen Sie sowohl den primären Knoten als auch den Standby-Knoten konfigurieren. In den folgenden Abschnitten werden die Schritte erläutert, die zu einer einfachen Konfiguration erforderlich sind.

Primärknoten konfigurieren

Sie können den primären Knoten für die Streaming-Replikation konfigurieren, indem Sie die folgenden Schritte ausführen:

Schritt 1: Initialisieren Sie die Datenbank

Um die Datenbank zu initialisieren, können Sie den initidb utility nutzen. Als Nächstes können Sie einen neuen Benutzer mit Replikationsberechtigungen erstellen, indem Sie den folgenden Befehl verwenden:

 CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD '';

Der Benutzer muss ein Passwort und einen Benutzernamen für die angegebene Abfrage angeben. Das Replikationsschlüsselwort wird verwendet, um dem Benutzer die erforderlichen Berechtigungen zu erteilen. Eine Beispielabfrage würde in etwa so aussehen:

 CREATE USER rep_user REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_pass'

Schritt 2: Streaming-Eigenschaften konfigurieren

Als Nächstes können Sie die Streaming-Eigenschaften mit der PostgreSQL-Konfigurationsdatei ( postgresql.conf ) konfigurieren, die wie folgt geändert werden kann:

 wal_level = logical wal_log_hints = on max_wal_senders = 8 max_wal_size = 1GB hot_standby = on

Hier ist ein kleiner Hintergrund zu den Parametern, die im vorherigen Snippet verwendet wurden:

• wal_log_hints : Dieser Parameter ist für die pg_rewind Funktion erforderlich, die praktisch ist, wenn der Standby-Server nicht mehr mit dem Primärserver synchronisiert ist.
• wal_level : Sie können diesen Parameter verwenden, um die PostgreSQL-Streaming-Replikation zu aktivieren, mit möglichen Werten wie minimal , replica oder logical .
• max_wal_size : Hiermit kann die Größe von WAL-Dateien angegeben werden, die in Protokolldateien aufbewahrt werden können.
• hot_standby : Sie können diesen Parameter für eine Read-on-Verbindung mit dem sekundären verwenden, wenn er auf ON gesetzt ist.
• max_wal_senders : Mit max_wal_senders können Sie die maximale Anzahl gleichzeitiger Verbindungen angeben, die mit den Standby-Servern aufgebaut werden können.

Schritt 3: Neuen Eintrag erstellen

Nachdem Sie die Parameter in der Datei postgresql.conf geändert haben, kann ein neuer Replikationseintrag in der Datei pg_hba.conf den Servern ermöglichen, eine Verbindung zur Replikation herzustellen.

Sie finden diese Datei normalerweise im Datenverzeichnis von PostgreSQL. Sie können dafür das folgende Code-Snippet verwenden:

 host replication rep_user IPaddress md5

Sobald das Code-Snippet ausgeführt wurde, ermöglicht der primäre Server einem Benutzer namens rep_user , sich zu verbinden und als Standby-Server zu fungieren, indem er die angegebene IP für die Replikation verwendet. Zum Beispiel:

 host replication rep_user 192.168.0.22/32 md5

Konfigurieren des Standby-Knotens

Gehen Sie folgendermaßen vor, um den Standby-Knoten für die Streaming-Replikation zu konfigurieren:

Schritt 1: Primärknoten sichern

Um den Standby-Knoten zu konfigurieren, nutzen Sie das Dienstprogramm pg_basebackup , um eine Sicherung des primären Knotens zu erstellen. Dies dient als Ausgangspunkt für den Standby-Knoten. Sie können dieses Dienstprogramm mit der folgenden Syntax verwenden:

 pg_basebackp -D -h -X stream -c fast -U rep_user -W

Die in der oben erwähnten Syntax verwendeten Parameter lauten wie folgt:

• -h : Sie können dies verwenden, um den primären Host zu erwähnen.
• -D : Dieser Parameter gibt das Verzeichnis an, an dem Sie gerade arbeiten.
• -C : Hiermit können Sie die Checkpoints setzen.
• -X : Dieser Parameter kann verwendet werden, um die erforderlichen Transaktionsprotokolldateien einzuschließen.
• -W : Sie können diesen Parameter verwenden, um den Benutzer zur Eingabe eines Kennworts aufzufordern, bevor eine Verknüpfung mit der Datenbank hergestellt wird.

Schritt 2: Replikationskonfigurationsdatei einrichten

Als Nächstes müssen Sie überprüfen, ob die Replikationskonfigurationsdatei vorhanden ist. Wenn dies nicht der Fall ist, können Sie die Replikationskonfigurationsdatei als recovery.conf generieren.

Sie sollten diese Datei im Datenverzeichnis der PostgreSQL-Installation erstellen. Sie können es automatisch generieren, indem Sie die Option -R im Dienstprogramm pg_basebackup .

Die Datei recovery.conf sollte die folgenden Befehle enthalten:

standby_mode = 'on'

primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name="host_name"'

recovery_target_timeline = 'neueste'

Die in den oben genannten Befehlen verwendeten Parameter lauten wie folgt:

• primary_conninfo : Sie können dies verwenden, um eine Verbindung zwischen dem primären und dem sekundären Server herzustellen, indem Sie eine Verbindungszeichenfolge nutzen.
• standby_mode : Dieser Parameter kann bewirken, dass der primäre Server beim Einschalten als Standby gestartet wird.
• recovery_target_timeline : Sie können dies verwenden, um die Wiederherstellungszeit festzulegen.

Um eine Verbindung einzurichten, müssen Sie den Benutzernamen, die IP-Adresse und das Kennwort als Werte für den Parameter primary_conninfo angeben. Zum Beispiel:

 primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'

Schritt 3: Starten Sie den sekundären Server neu

Abschließend können Sie den sekundären Server neu starten, um den Konfigurationsprozess abzuschließen.

Die Streaming-Replikation ist jedoch mit mehreren Herausforderungen verbunden, wie z.

• Verschiedene PostgreSQL-Clients (geschrieben in verschiedenen Programmiersprachen) kommunizieren mit einem einzigen Endpunkt. Wenn der primäre Knoten ausfällt, versuchen diese Clients immer wieder denselben DNS- oder IP-Namen. Dadurch wird das Failover für die Anwendung sichtbar.
• Die PostgreSQL-Replikation verfügt nicht über integriertes Failover und Monitoring. Wenn der primäre Knoten ausfällt, müssen Sie einen sekundären zum neuen primären Knoten machen. Diese Heraufstufung muss so ausgeführt werden, dass Clients nur auf einen primären Knoten schreiben und keine Dateninkonsistenzen feststellen.
• PostgreSQL repliziert seinen gesamten Zustand. Wenn Sie einen neuen sekundären Knoten entwickeln müssen, muss der sekundäre Knoten den gesamten Verlauf der Zustandsänderung vom primären Knoten rekapitulieren, was ressourcenintensiv ist und es kostspielig macht, Knoten im Kopf zu eliminieren und neue zu erstellen.

Ansatz 2: Repliziertes Blockgerät

Der Ansatz mit replizierten Blockgeräten hängt von der Festplattenspiegelung ab (auch bekannt als Volume-Replikation). Bei diesem Ansatz werden Änderungen auf ein persistentes Volume geschrieben, das synchron auf ein anderes Volume gespiegelt wird.

Der zusätzliche Vorteil dieses Ansatzes ist seine Kompatibilität und Datenbeständigkeit in Cloud-Umgebungen mit allen relationalen Datenbanken, einschließlich PostgreSQL, MySQL und SQL Server, um nur einige zu nennen.

Der Disk-Mirroring-Ansatz für die PostgreSQL-Replikation erfordert jedoch, dass Sie sowohl WAL-Protokoll- als auch Tabellendaten replizieren. Da jetzt jeder Schreibvorgang in die Datenbank synchron über das Netzwerk gehen muss, können Sie es sich nicht leisten, ein einziges Byte zu verlieren, da dies Ihre Datenbank in einem beschädigten Zustand hinterlassen könnte.

Dieser Ansatz wird normalerweise mithilfe von Azure PostgreSQL und Amazon RDS genutzt.

Ansatz 3: WAL

WAL besteht aus Segmentdateien (standardmäßig 16 MB). Jedes Segment hat einen oder mehrere Datensätze. Ein Protokollsequenzdatensatz (LSN) ist ein Zeiger auf einen Datensatz in WAL, der Ihnen die Position/den Ort mitteilt, an dem der Datensatz in der Protokolldatei gespeichert wurde.

Ein Standby-Server nutzt WAL-Segmente – in der PostgreSQL-Terminologie auch als XLOGS bezeichnet –, um kontinuierlich Änderungen von seinem Primärserver zu replizieren. Sie können die Write-Ahead-Protokollierung verwenden, um Dauerhaftigkeit und Atomarität in einem DBMS zu gewährleisten, indem Sie Blöcke von Byte-Array-Daten (jede mit einer eindeutigen LSN) in einen stabilen Speicher serialisieren, bevor sie auf eine Datenbank angewendet werden.

Das Anwenden einer Mutation auf eine Datenbank kann zu verschiedenen Dateisystemoperationen führen. Eine relevante Frage, die sich stellt, ist, wie eine Datenbank Atomarität im Falle eines Serverausfalls aufgrund eines Stromausfalls sicherstellen kann, während sie sich mitten in einer Dateisystemaktualisierung befand. Wenn eine Datenbank hochfährt, startet sie einen Start- oder Wiedergabeprozess, der die verfügbaren WAL-Segmente lesen kann und sie mit der auf jeder Datenseite gespeicherten LSN vergleicht (jede Datenseite ist mit der LSN des letzten WAL-Eintrags gekennzeichnet, der die Seite betrifft).

Auf Protokollversand basierende Replikation (Blockebene)

Die Streamingreplikation verfeinert den Protokollversandprozess. Im Gegensatz zum Warten auf den WAL-Switch werden die Datensätze gesendet, während sie erstellt werden, wodurch die Replikationsverzögerung verringert wird.

Die Streaming-Replikation übertrumpft auch den Protokollversand, da der Standby-Server mithilfe eines Replikationsprotokolls über das Netzwerk mit dem primären Server verbunden ist. Der primäre Server kann dann WAL-Einträge direkt über diese Verbindung senden, ohne auf vom Endbenutzer bereitgestellte Skripte angewiesen zu sein.

Auf Protokollversand basierende Replikation (Dateiebene)

Der Protokollversand ist definiert als das Kopieren von Protokolldateien auf einen anderen PostgreSQL-Server, um durch die Wiedergabe von WAL-Dateien einen weiteren Standby-Server zu generieren. Dieser Server ist so konfiguriert, dass er im Wiederherstellungsmodus arbeitet, und sein einziger Zweck besteht darin, alle neuen WAL-Dateien anzuwenden, sobald sie angezeigt werden.

Dieser sekundäre Server wird dann zu einem warmen Backup des primären PostgreSQL-Servers. Es kann auch als Lesereplikat konfiguriert werden, wo es schreibgeschützte Abfragen anbieten kann, die auch als Hot Standby bezeichnet werden.

Kontinuierliche WAL-Archivierung

Das Duplizieren von WAL-Dateien, während sie erstellt werden, an einem anderen Ort als dem Unterverzeichnis pg_wal , um sie zu archivieren, wird als WAL-Archivierung bezeichnet. PostgreSQL ruft jedes Mal, wenn eine WAL-Datei erstellt wird, ein vom Benutzer angegebenes Skript zur Archivierung auf.

Das Skript kann den scp -Befehl nutzen, um die Datei an einem oder mehreren Speicherorten wie einem NFS-Mount zu duplizieren. Nach der Archivierung können die WAL-Segmentdateien genutzt werden, um die Datenbank zu jedem beliebigen Zeitpunkt wiederherzustellen.

Andere protokollbasierte Konfigurationen umfassen:

• Synchrone Replikation : Bevor jede synchrone Replikationstransaktion festgeschrieben wird, wartet der primäre Server, bis Standby-Server bestätigen, dass sie die Daten erhalten haben. Der Vorteil dieser Konfiguration ist, dass keine Konflikte durch parallele Schreibvorgänge entstehen.
• Synchrone Multi-Master-Replikation : Hier kann jeder Server Schreibanfragen akzeptieren, und geänderte Daten werden vom ursprünglichen Server an jeden anderen Server übertragen, bevor jede Transaktion festgeschrieben wird. Es nutzt das 2PC-Protokoll und hält sich an die Alles-oder-Nichts-Regel.

Einzelheiten zum WAL-Streaming-Protokoll

Ein als WAL-Empfänger bekannter Prozess, der auf dem Standby-Server ausgeführt wird, nutzt die im Parameter primary_conninfo von recovery.conf bereitgestellten Verbindungsdetails und stellt über eine TCP/IP-Verbindung eine Verbindung zum Primärserver her.

Um die Streaming-Replikation zu starten, kann das Front-End den Replikationsparameter in der Startnachricht senden. Ein boolescher Wert von true, yes, 1 oder ON teilt dem Back-End mit, dass es in den Walsender-Modus für die physische Replikation wechseln muss.

WAL-Sender ist ein weiterer Prozess, der auf dem primären Server ausgeführt wird und dafür zuständig ist, die WAL-Einträge an den Standby-Server zu senden, sobald sie generiert werden. Der WAL-Empfänger speichert die WAL-Einträge in WAL, als ob sie durch Client-Aktivität von lokal verbundenen Clients erstellt worden wären.

Sobald die WAL-Datensätze die WAL-Segmentdateien erreichen, gibt der Standby-Server die WAL ständig wieder, sodass Primär- und Standby-Server auf dem neuesten Stand sind.

Elemente der PostgreSQL-Replikation

In diesem Abschnitt erhalten Sie ein tieferes Verständnis der häufig verwendeten Modelle (Single-Master- und Multi-Master-Replikation), Typen (physische und logische Replikation) und Modi (synchron und asynchron) der PostgreSQL-Replikation.

Modelle der PostgreSQL-Datenbankreplikation

Skalierbarkeit bedeutet das Hinzufügen von mehr Ressourcen/Hardware zu vorhandenen Knoten, um die Fähigkeit der Datenbank zu verbessern, mehr Daten zu speichern und zu verarbeiten, was horizontal und vertikal erreicht werden kann. PostgreSQL-Replikation ist ein Beispiel für horizontale Skalierbarkeit, die viel schwieriger zu implementieren ist als vertikale Skalierbarkeit. Horizontale Skalierbarkeit erreichen wir hauptsächlich durch Single-Master-Replikation (SMR) und Multi-Master-Replikation (MMR).

Bei der Single-Master-Replikation können Daten nur auf einem einzelnen Knoten geändert werden, und diese Änderungen werden auf einen oder mehrere Knoten repliziert. Die replizierten Tabellen in der Replikatdatenbank dürfen keine Änderungen akzeptieren, außer denen vom primären Server. Selbst wenn dies der Fall ist, werden die Änderungen nicht zurück auf den primären Server repliziert.

Meistens reicht SMR für die Anwendung aus, da es weniger kompliziert zu konfigurieren und zu verwalten ist und keine Konflikte auftreten können. Die Single-Master-Replikation ist ebenfalls unidirektional, da Replikationsdaten hauptsächlich in eine Richtung fließen, von der primären zur Replikatdatenbank.

In einigen Fällen ist SMR allein möglicherweise nicht ausreichend, und Sie müssen möglicherweise MMR implementieren. MMR ermöglicht es mehr als einem Knoten, als primärer Knoten zu fungieren. Änderungen an Tabellenzeilen in mehr als einer bestimmten Primärdatenbank werden in ihre Gegenstücktabellen in jeder anderen Primärdatenbank repliziert. In diesem Modell werden häufig Konfliktlösungsschemata eingesetzt, um Probleme wie doppelte Primärschlüssel zu vermeiden.

Die Verwendung von MMR hat einige Vorteile, nämlich:

• Im Falle eines Hostausfalls können andere Hosts immer noch Aktualisierungs- und Einfügungsdienste erbringen.
• Die primären Knoten sind auf mehrere verschiedene Standorte verteilt, sodass die Wahrscheinlichkeit eines Ausfalls aller primären Knoten sehr gering ist.
• Fähigkeit, ein WAN (Wide Area Network) mit primären Datenbanken zu verwenden, die sich geografisch in der Nähe von Clientgruppen befinden können, und dennoch die Datenkonsistenz im gesamten Netzwerk aufrechterhalten.

Die Kehrseite der Implementierung von MMR ist jedoch die Komplexität und die Schwierigkeit, Konflikte zu lösen.

Mehrere Zweige und Anwendungen bieten MMR-Lösungen, da PostgreSQL sie nicht nativ unterstützt. Diese Lösungen können Open Source, kostenlos oder kostenpflichtig sein. Eine solche Erweiterung ist die bidirektionale Replikation (BDR), die asynchron ist und auf der logischen Dekodierungsfunktion von PostgreSQL basiert.

Da die BDR-Anwendung Transaktionen auf anderen Knoten wiedergibt, kann der Wiedergabevorgang fehlschlagen, wenn ein Konflikt zwischen der angewendeten Transaktion und der auf dem empfangenden Knoten festgeschriebenen Transaktion besteht.

Arten der PostgreSQL-Replikation

Es gibt zwei Arten der PostgreSQL-Replikation: logische und physische Replikation.

Eine einfache logische Operation „initdb“ würde die physische Operation zum Erstellen eines Basisverzeichnisses für einen Cluster ausführen. Ebenso würde eine einfache logische Operation „CREATE DATABASE“ die physische Operation zum Erstellen eines Unterverzeichnisses im Basisverzeichnis ausführen.

Die physische Replikation befasst sich normalerweise mit Dateien und Verzeichnissen. Es weiß nicht, was diese Dateien und Verzeichnisse darstellen. Diese Methoden werden verwendet, um eine vollständige Kopie der gesamten Daten eines einzelnen Clusters zu verwalten, normalerweise auf einem anderen Computer, und werden auf Dateisystemebene oder Festplattenebene durchgeführt und verwenden genaue Blockadressen.

Die logische Replikation ist eine Methode zur Reproduktion von Datenentitäten und deren Änderungen auf der Grundlage ihrer Replikationsidentität (normalerweise ein Primärschlüssel). Im Gegensatz zur physischen Replikation befasst sie sich mit Datenbanken, Tabellen und DML-Vorgängen und erfolgt auf Datenbank-Cluster-Ebene. Es verwendet ein Veröffentlichungs- und Abonnementmodell , bei dem ein oder mehrere Abonnenten eine oder mehrere Veröffentlichungen auf einem Herausgeberknoten abonniert haben.

Der Replikationsprozess beginnt damit, dass ein Snapshot der Daten in der Herausgeberdatenbank erstellt und dann auf den Abonnenten kopiert wird. Abonnenten ziehen Daten aus den Veröffentlichungen, die sie abonniert haben, und können Daten später erneut veröffentlichen, um eine kaskadierende Replikation oder komplexere Konfigurationen zu ermöglichen. Der Abonnent wendet die Daten in derselben Reihenfolge wie der Herausgeber an, sodass die Transaktionskonsistenz für Veröffentlichungen innerhalb eines einzelnen Abonnements, auch als Transaktionsreplikation bezeichnet, gewährleistet ist.

Die typischen Anwendungsfälle für die logische Replikation sind:

• Senden inkrementeller Änderungen in einer einzelnen Datenbank (oder einer Teilmenge einer Datenbank) an Abonnenten, sobald sie auftreten.
• Teilen einer Teilmenge der Datenbank durch mehrere Datenbanken.
• Auslösen des Auslösens einzelner Änderungen, wenn sie beim Abonnenten ankommen.
• Konsolidierung mehrerer Datenbanken zu einer.
• Bereitstellung des Zugriffs auf replizierte Daten für verschiedene Benutzergruppen.

Die Abonnentendatenbank verhält sich genauso wie jede andere PostgreSQL-Instanz und kann als Herausgeber für andere Datenbanken verwendet werden, indem ihre Veröffentlichungen definiert werden.

Wenn der Abonnent von der Anwendung als schreibgeschützt behandelt wird, gibt es keine Konflikte von einem einzelnen Abonnement. Wenn andererseits andere Schreibvorgänge entweder von einer Anwendung oder von anderen Subskribenten in denselben Satz von Tabellen ausgeführt werden, können Konflikte entstehen.

PostgreSQL unterstützt beide Mechanismen gleichzeitig. Die logische Replikation ermöglicht eine detaillierte Kontrolle über die Datenreplikation und die Sicherheit.

Replikationsmodi

Es gibt hauptsächlich zwei Modi der PostgreSQL-Replikation: synchron und asynchron. Die synchrone Replikation ermöglicht das gleichzeitige Schreiben von Daten auf den primären und den sekundären Server, während die asynchrone Replikation sicherstellt, dass die Daten zuerst auf den Host geschrieben und dann auf den sekundären Server kopiert werden.

Bei der Replikation im synchronen Modus gelten Transaktionen in der Primärdatenbank nur dann als abgeschlossen, wenn diese Änderungen auf alle Replikate repliziert wurden. Alle Replica-Server müssen ständig verfügbar sein, damit die Transaktionen auf dem Primärserver abgeschlossen werden können. Der synchrone Replikationsmodus wird in High-End-Transaktionsumgebungen mit sofortigen Failover-Anforderungen verwendet.

Im asynchronen Modus können Transaktionen auf dem primären Server für abgeschlossen erklärt werden, wenn die Änderungen nur auf dem primären Server vorgenommen wurden. Diese Änderungen werden dann später in den Replikaten repliziert. Die Replikatserver können für eine bestimmte Dauer, die als Replikationsverzögerung bezeichnet wird, nicht synchron bleiben. Im Falle eines Absturzes kann es zu Datenverlust kommen, aber der durch die asynchrone Replikation verursachte Overhead ist gering, sodass er in den meisten Fällen akzeptabel ist (der Host wird nicht überlastet). Das Failover von der primären Datenbank zur sekundären Datenbank dauert länger als die synchrone Replikation.

So richten Sie die PostgreSQL-Replikation ein

In diesem Abschnitt zeigen wir Ihnen, wie Sie den PostgreSQL-Replikationsprozess auf einem Linux-Betriebssystem einrichten. Für dieses Beispiel verwenden wir Ubuntu 18.04 LTS und PostgreSQL 10.

Lassen Sie uns graben!

Installation

Sie beginnen mit der Installation von PostgreSQL unter Linux mit diesen Schritten:

1. Zunächst müssten Sie den PostgreSQL-Signaturschlüssel importieren, indem Sie den folgenden Befehl im Terminal eingeben:

    wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -

2. Fügen Sie dann das PostgreSQL-Repository hinzu, indem Sie den folgenden Befehl im Terminal eingeben:

    echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list

3. Aktualisieren Sie den Repository-Index, indem Sie den folgenden Befehl im Terminal eingeben:

    sudo apt-get update

4. Installieren Sie das PostgreSQL-Paket mit dem apt-Befehl:

    sudo apt-get install -y postgresql-10

5. Legen Sie schließlich das Passwort für den PostgreSQL-Benutzer mit dem folgenden Befehl fest:

    sudo passwd postgres

Die Installation von PostgreSQL ist sowohl für den primären als auch für den sekundären Server obligatorisch, bevor der PostgreSQL-Replikationsprozess gestartet wird.

Nachdem Sie PostgreSQL für beide Server eingerichtet haben, können Sie mit der Einrichtung der Replikation des primären und des sekundären Servers fortfahren.

Replikation im Primärserver einrichten

Führen Sie diese Schritte aus, nachdem Sie PostgreSQL sowohl auf dem primären als auch auf dem sekundären Server installiert haben.

1. Melden Sie sich zunächst mit dem folgenden Befehl bei der PostgreSQL-Datenbank an:

    su - postgres

2. Erstellen Sie mit dem folgenden Befehl einen Replikationsbenutzer:

    psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"

3. Bearbeiten Sie pg_hba.cnf mit einer beliebigen Nano-Anwendung in Ubuntu und fügen Sie die folgende Konfiguration hinzu: Dateibearbeitungsbefehl

    nano /etc/postgresql/10/main/pg_hba.conf

   Verwenden Sie zum Konfigurieren der Datei den folgenden Befehl:

    host replication replication MasterIP/24 md5

4. Öffnen und bearbeiten Sie postgresql.conf und legen Sie die folgende Konfiguration auf dem primären Server ab:

    nano /etc/postgresql/10/main/postgresql.conf

   Verwenden Sie die folgenden Konfigurationseinstellungen:
   

    listen_addresses = 'localhost,MasterIP'

    wal_level = replica

    wal_keep_segments = 64

    max_wal_senders = 10

5. Starten Sie abschließend PostgreSQL auf dem primären Hauptserver neu:

 systemctl restart postgresql

Sie haben jetzt die Einrichtung auf dem primären Server abgeschlossen.

Einrichten der Replikation auf dem sekundären Server

Befolgen Sie diese Schritte, um die Replikation auf dem sekundären Server einzurichten:

1. Melden Sie sich mit dem folgenden Befehl bei PostgreSQL RDMS an:

    su - postgres

2. Beenden Sie die Arbeit des PostgreSQL-Dienstes, damit wir mit dem folgenden Befehl daran arbeiten können:

    systemctl stop postgresql

3. Bearbeiten Sie die Datei pg_hba.conf mit diesem Befehl und fügen Sie die folgende Konfiguration hinzu:
   Befehl bearbeiten
   

    nano /etc/postgresql/10/main/pg_hba.conf

   Aufbau
   

    host replication replication MasterIP/24 md5

4. Öffnen und bearbeiten Sie postgresql.conf auf dem sekundären Server und fügen Sie die folgende Konfiguration ein oder kommentieren Sie sie aus, wenn sie kommentiert ist: Befehl bearbeiten
   
   Aufbau
   

    nano /etc/postgresql/10/main/postgresql.conf

    listen_addresses = 'localhost,SecondaryIP'

    wal_keep_segments = 64

    wal_level = replica

    hot_standby = on

    max_wal_senders = 10

   SecondaryIP ist die Adresse des sekundären Servers

5. Greifen Sie auf das PostgreSQL-Datenverzeichnis auf dem sekundären Server zu und entfernen Sie alles:

    cd /var/lib/postgresql/10/main

    rm -rfv *

6. Kopieren Sie die Datenverzeichnisdateien des PostgreSQL-Primärservers in das Datenverzeichnis des PostgreSQL-Sekundärservers und schreiben Sie diesen Befehl in den Sekundärserver:

    pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U

    replication --wal-method=fetch

7. Geben Sie das PostgreSQL-Passwort des primären Servers ein und drücken Sie die Eingabetaste. Fügen Sie als Nächstes den folgenden Befehl für die Wiederherstellungskonfiguration hinzu: Befehl bearbeiten
   

    nano /var/lib/postgresql/10/main/recovery.conf

   Aufbau
   

    standby_mode = 'on' primary_conninfo = 'host=MasterIP port=5432 user=replication password=YOUR_PASSWORD' trigger_file = '/tmp/MasterNow'

   Hier ist YOUR_PASSWORD das Passwort für den Replikationsbenutzer im Primärserver, den PostgreSQL erstellt

8. Nachdem das Passwort festgelegt wurde, müssen Sie die sekundäre PostgreSQL-Datenbank neu starten, da sie gestoppt wurde:

 systemctl start postgresql

Testen Ihres Setups

Nachdem wir die Schritte ausgeführt haben, testen wir den Replikationsprozess und beobachten die sekundäre Serverdatenbank. Dazu erstellen wir eine Tabelle auf dem primären Server und beobachten, ob sich dieselbe auf dem sekundären Server widerspiegelt.

Lasst uns anfangen.

1. Da wir die Tabelle auf dem Primärserver erstellen, müssen Sie sich beim Primärserver anmelden:

    su - postgres psql

2. Jetzt erstellen wir eine einfache Tabelle namens ‚testtable‘ und fügen Daten in die Tabelle ein, indem wir die folgenden PostgreSQL-Abfragen im Terminal ausführen:

    CREATE TABLE testtable (websites varchar(100)); INSERT INTO testtable VALUES ('section.com'); INSERT INTO testtable VALUES ('google.com'); INSERT INTO testtable VALUES ('github.com');

3. Beobachten Sie die PostgreSQL-Datenbank des sekundären Servers, indem Sie sich beim sekundären Server anmelden:

    su - postgres psql

4. Jetzt prüfen wir, ob die Tabelle ‚testtable‘ existiert, und können die Daten zurückgeben, indem wir die folgenden PostgreSQL-Abfragen im Terminal ausführen. Dieser Befehl zeigt im Wesentlichen die gesamte Tabelle an.

    select * from testtable;

Dies ist die Ausgabe der Testtabelle:

 | websites | ------------------- | section.com | | google.com | | github.com | --------------------

Sie sollten in der Lage sein, die gleichen Daten wie auf dem primären Server zu beobachten.

Wenn Sie das oben sehen, haben Sie den Replikationsprozess erfolgreich durchgeführt!

Was sind die manuellen PostgreSQL-Failover-Schritte?

Gehen wir die Schritte für ein manuelles PostgreSQL-Failover durch:

1. Absturz des primären Servers.
2. Stufen Sie den Standby-Server hoch, indem Sie den folgenden Befehl auf dem Standby-Server ausführen:

    ./pg_ctl promote -D ../sb_data/ server promoting

3. Verbinden Sie sich mit dem hochgestuften Standby-Server und fügen Sie eine Zeile ein:

    -bash-4.2$ ./edb-psql -p 5432 edb Password: psql.bin (10.7) Type "help" for help. edb=# insert into abc values (4,'Four');

Wenn das Einfügen problemlos funktioniert, wurde der Standby-Server, der zuvor ein Nur-Lese-Server war, zum neuen Primärserver hochgestuft.

So automatisieren Sie Failover in PostgreSQL

Die Einrichtung eines automatischen Failover ist einfach.

Sie benötigen den EDB PostgreSQL Failover Manager (EFM). Nach dem Herunterladen und Installieren von EFM auf jedem primären und Standby-Knoten können Sie einen EFM-Cluster erstellen, der aus einem primären Knoten, einem oder mehreren Standby-Knoten und einem optionalen Witness-Knoten besteht, der Behauptungen im Fehlerfall bestätigt.

EFM überwacht kontinuierlich den Systemzustand und sendet E-Mail-Warnungen basierend auf Systemereignissen. Wenn ein Ausfall auftritt, schaltet er automatisch auf den aktuellsten Standby-Server um und konfiguriert alle anderen Standby-Server neu, um den neuen primären Knoten zu erkennen.

Es konfiguriert auch Load Balancer (wie pgPool) neu und verhindert das Auftreten von „Split-Brain“ (wenn zwei Knoten sich jeweils für primär halten).

Zusammenfassung

Aufgrund großer Datenmengen sind Skalierbarkeit und Sicherheit zwei der wichtigsten Kriterien im Datenbankmanagement, insbesondere im Transaktionsumfeld. Obwohl wir die Skalierbarkeit vertikal verbessern können, indem wir mehr Ressourcen/Hardware zu vorhandenen Knoten hinzufügen, ist dies nicht immer möglich, häufig aufgrund der Kosten oder Einschränkungen beim Hinzufügen neuer Hardware.

Daher ist eine horizontale Skalierbarkeit erforderlich, was bedeutet, dass mehr Knoten zu bestehenden Netzwerkknoten hinzugefügt werden, anstatt die Funktionalität bestehender Knoten zu verbessern. Hier kommt die PostgreSQL-Replikation ins Spiel.
Um die Integrität Ihrer Website zu schützen, ist es wichtig, Sicherheitsvorkehrungen gegen mögliche Ausfallzeiten oder Datenverluste zu treffen. Erfahren Sie mehr in diesem Leitfaden Click to Tweet
In diesem Artikel haben wir die Arten von PostgreSQL-Replikationen, Vorteile, Replikationsmodi, Installation und PostgreSQL-Failover zwischen SMR und MMR besprochen. Lassen Sie uns jetzt von Ihnen hören.

Welche setzen Sie normalerweise um? Welche Datenbankfunktion ist Ihnen am wichtigsten und warum? Wir würden gerne Ihre Gedanken lesen! Teilen Sie sie im Kommentarbereich unten.