Die Replikation zwischen zwei Datenbanken bietet Fehlertoleranz gegen unerwartete Pannen. Sie gilt als die beste Strategie, um im Katastrophenfall eine hohe Verf\u00fcgbarkeit zu erreichen.<\/p>\n
In diesem Artikel befassen wir uns mit den verschiedenen Strategien, die Backend-Entwickler\/innen<\/a> f\u00fcr eine nahtlose PostgreSQL-Replikation einsetzen k\u00f6nnen.<\/p>\n Unter PostgreSQL-Replikation versteht man den Prozess des Kopierens von Daten von einem PostgreSQL-Datenbankserver<\/a> auf einen anderen Server. Der Quelldatenbankserver wird auch als „prim\u00e4rer“ Server bezeichnet, w\u00e4hrend der Datenbankserver, der die kopierten Daten erh\u00e4lt, als „Replikatserver“ bezeichnet wird.<\/p>\n Die PostgreSQL-Datenbank folgt einem einfachen Replikationsmodell, bei dem alle Schreibvorg\u00e4nge an einen prim\u00e4ren Knoten gehen. Der prim\u00e4re Knoten kann dann die \u00c4nderungen \u00fcbernehmen und sie an die sekund\u00e4ren Knoten weiterleiten.<\/p>\n Failover ist eine Methode zur Wiederherstellung von Daten, wenn der Hauptserver aus irgendeinem Grund ausf\u00e4llt<\/a>. Solange du PostreSQL so konfiguriert hast, dass es deine physische Streaming-Replikation verwaltet, sind du – und deine Nutzer – vor Ausf\u00e4llen aufgrund eines Ausfalls des Prim\u00e4rservers gesch\u00fctzt.<\/p>\n Beachte, dass es einige Zeit dauern kann, den Failover-Prozess einzurichten und zu starten. Es gibt keine eingebauten Tools, um Serverausf\u00e4lle in PostgreSQL zu \u00fcberwachen und zu erfassen, du musst also kreativ werden.<\/p>\n Zum Gl\u00fcck bist du beim Failover nicht auf PostgreSQL angewiesen. Es gibt spezielle Tools, die ein automatisches Failover und ein automatisches Umschalten auf den Standby-Server erm\u00f6glichen und so die Ausfallzeiten der Datenbank<\/a> reduzieren.<\/p>\n Wenn du eine Failover-Replikation einrichtest, garantierst du praktisch Hochverf\u00fcgbarkeit, indem du sicherstellst, dass der Standby-Server verf\u00fcgbar ist, falls der prim\u00e4re Server einmal ausf\u00e4llt.<\/p>\n Hier sind einige der wichtigsten Vorteile der PostgreSQL-Replikation:<\/p>\n Im Allgemeinen glauben die Leute, dass es nur einen Weg gibt, Backups<\/a> und Replikationen einzurichten, wenn du mit einer prim\u00e4ren und sekund\u00e4ren Architektur arbeitest. PostgreSQL-Implementierungen k\u00f6nnen jedoch jeder dieser drei Methoden<\/a> folgen:<\/p>\n 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\u00e4r- zur Zieldatenbank.<\/p>\n Du kannst die PostgreSQL-Streaming-Replikation mit einer Prim\u00e4r-Sekund\u00e4r-Konfiguration implementieren. Der prim\u00e4re Server ist die Hauptinstanz, die die prim\u00e4re Datenbank und alle ihre Operationen verwaltet. Der sekund\u00e4re Server fungiert als zus\u00e4tzliche Instanz und f\u00fchrt alle \u00c4nderungen an der prim\u00e4ren Datenbank auf sich selbst aus, wobei er eine identische Kopie erzeugt. Der Prim\u00e4rserver ist der Lese-\/Schreibserver, w\u00e4hrend der Sekund\u00e4rserver nur Lesezugriff hat.<\/p>\n Bei dieser Methode musst du sowohl den prim\u00e4ren als auch den Standby-Knoten konfigurieren. In den folgenden Abschnitten werden die Schritte erl\u00e4utert, die f\u00fcr eine einfache Konfiguration erforderlich sind.<\/p>\n Du kannst den Prim\u00e4rknoten f\u00fcr die Streaming-Replikation konfigurieren, indem du die folgenden Schritte durchf\u00fchrst:<\/p>\n Um die Datenbank zu initialisieren<\/a>, kannst du den Dienstprogrammbefehl Der Benutzer muss ein Passwort und einen Benutzernamen f\u00fcr die angegebene Abfrage angeben. Das Schl\u00fcsselwort replication wird verwendet, um dem Benutzer die erforderlichen Rechte zu geben. Eine Beispielabfrage w\u00fcrde etwa so aussehen:<\/p>\n Als N\u00e4chstes kannst du die Streaming-Eigenschaften in der PostgreSQL-Konfigurationsdatei (postgresql.conf<\/strong>) konfigurieren, die wie folgt ge\u00e4ndert werden kann:<\/p>\n Hier ein paar Hintergrundinformationen zu den Parametern, die im vorherigen Snippet verwendet wurden:<\/p>\n Nachdem du die Parameter in der Datei postgresql.conf<\/strong> ge\u00e4ndert hast, kann ein neuer Replikationseintrag in der Datei pg_hba.conf<\/strong> daf\u00fcr sorgen, dass die Server f\u00fcr die Replikation eine Verbindung zueinander aufbauen.<\/p>\n Du findest diese Datei normalerweise im Datenverzeichnis von PostgreSQL. Du kannst daf\u00fcr den folgenden Codeausschnitt verwenden:<\/p>\n Sobald das Codeschnipsel ausgef\u00fchrt wird, erlaubt der Prim\u00e4rserver einem Benutzer namens Um den Standby-Knoten f\u00fcr die Streaming-Replikation zu konfigurieren, befolgst du die folgenden Schritte:<\/p>\n Um den Standby-Knoten zu konfigurieren, erstellst du mit dem Dienstprogramm Die in der oben genannten Syntax verwendeten Parameter lauten wie folgt:<\/p>\n Als N\u00e4chstes musst du pr\u00fcfen, ob die Replikationskonfigurationsdatei existiert. Ist dies nicht der Fall, kannst du die Replikationskonfigurationsdatei als recovery.conf<\/strong> erstellen.<\/p>\n Du solltest diese Datei im Datenverzeichnis der PostgreSQL-Installation erstellen. Du kannst sie automatisch erstellen, indem du die Option Die Datei recovery.conf<\/strong> sollte die folgenden Befehle enthalten:<\/p>\n Die in den oben genannten Befehlen verwendeten Parameter lauten wie folgt:<\/p>\n Um eine Verbindung einzurichten, musst du den Benutzernamen, die IP-Adresse und das Passwort als Werte f\u00fcr den Parameter primary_conninfo angeben. Zum Beispiel:<\/p>\n Zum Schluss kannst du den Sekund\u00e4rserver neu starten, um den Konfigurationsprozess abzuschlie\u00dfen.<\/p>\n Die Streaming-Replikation bringt jedoch einige Herausforderungen mit sich, wie zum Beispiel:<\/p>\n Der Methode des replizierten Blockger\u00e4ts basiert auf der Spiegelung von Festplatten (auch bekannt als Volume-Replikation). Bei diesem Ansatz werden \u00c4nderungen auf ein persistentes Volume geschrieben, das synchron auf ein anderes Volume gespiegelt wird.<\/p>\n Der zus\u00e4tzliche Vorteil dieses Methode ist die Kompatibilit\u00e4t und Datenbest\u00e4ndigkeit in Cloud-Umgebungen mit allen relationalen Datenbanken, wie PostgreSQL, MySQL und SQL Server<\/a>, um nur einige zu nennen.<\/p>\n Bei der PostgreSQL-Replikation mit Disk-Mirroring musst du jedoch sowohl die WAL-Log- als auch die Tabellendaten replizieren. Da jeder Schreibvorgang in die Datenbank nun synchron \u00fcber das Netzwerk erfolgen muss, kannst du es dir nicht erlauben, auch nur ein einziges Byte zu verlieren, da deine Datenbank sonst besch\u00e4digt werden k\u00f6nnte.<\/p>\n Dieser Methode wird normalerweise mit Azure PostgreSQL und Amazon RDS genutzt.<\/p>\n WAL besteht aus Segmentdateien (standardm\u00e4\u00dfig 16 MB). Jedes Segment enth\u00e4lt einen oder mehrere Datens\u00e4tze. Ein Log Sequence Record (LSN) ist ein Zeiger auf einen Datensatz in der WAL, der dir die Position\/den Ort angibt, an dem der Datensatz in der Logdatei gespeichert wurde.<\/p>\n Ein Standby-Server nutzt WAL-Segmente – in der PostgreSQL-Terminologie auch XLOGS genannt -, um \u00c4nderungen des Prim\u00e4rservers kontinuierlich zu replizieren. Du kannst Write-Ahead-Logging verwenden, um Haltbarkeit und Atomarit\u00e4t in einem DBMS zu gew\u00e4hrleisten, indem du Datenpakete aus Byte-Arrays (jedes mit einer eindeutigen LSN) in einen stabilen Speicher serialisierst, bevor sie auf eine Datenbank angewendet werden.<\/p>\n Die Anwendung einer Mutation auf eine Datenbank kann zu verschiedenen Dateisystemoperationen f\u00fchren. Eine wichtige Frage, die sich stellt, ist, wie eine Datenbank die Atomarit\u00e4t im Falle eines Serverausfalls aufgrund eines Stromausfalls sicherstellen kann, w\u00e4hrend sie mitten in einer Dateisystemaktualisierung steckt. Wenn eine Datenbank hochf\u00e4hrt, startet sie einen Start- oder Replay-Prozess, der die verf\u00fcgbaren WAL-Segmente lesen kann und sie mit der LSN vergleicht, die auf jeder Datenseite gespeichert ist (jede Datenseite ist mit der LSN des letzten WAL-Datensatzes markiert, der die Seite betrifft).<\/p>\n Die Streaming-Replikation verfeinert den Log-Shipping-Prozess. Anstatt auf den WAL-Wechsel zu warten, werden die Datens\u00e4tze gesendet, sobald sie erstellt werden.<\/p>\n Die Streaming-Replikation \u00fcbertrumpft auch den Log-Versand, weil der Standby-Server \u00fcber das Netzwerk mit dem Prim\u00e4rserver verbunden ist, indem er ein Replikationsprotokoll nutzt. Der Prim\u00e4rserver kann dann WAL-Datens\u00e4tze direkt \u00fcber diese Verbindung senden, ohne auf Skripte angewiesen zu sein, die vom Endbenutzer bereitgestellt werden.<\/p>\n Unter Log Shipping versteht man das Kopieren von Logdateien auf einen anderen PostgreSQL-Server, um einen weiteren Standby-Server durch die Wiedergabe von WAL-Dateien zu erzeugen. Dieser Server ist so konfiguriert, dass er im Wiederherstellungsmodus arbeitet, und sein einziger Zweck ist es, alle neuen WAL-Dateien anzuwenden, sobald sie auftauchen.<\/p>\n Dieser sekund\u00e4re Server wird dann zu einem Warm-Backup des prim\u00e4ren PostgreSQL-Servers. Er kann auch als Read Replica konfiguriert werden, so dass er nur Leseabfragen durchf\u00fchren kann, was auch als Hot Standby bezeichnet wird.<\/p>\n Das Duplizieren von WAL-Dateien, sobald sie erstellt werden, in ein anderes Verzeichnis als das Unterverzeichnis Das Skript kann den Befehl Weitere logbasierte Konfigurationen sind:<\/p>\n Ein Prozess, der als WAL-Receiver bezeichnet wird, und auf dem Standby-Server l\u00e4uft, nutzt die Verbindungsdetails, die im Parameter Um die Streaming-Replikation zu starten, kann das Frontend den Replikationsparameter in der Startnachricht senden. Ein boolescher Wert von true, yes, 1 oder ON teilt dem Backend<\/a> mit, dass es in den physischen Replikations-Walsender-Modus wechseln muss.<\/p>\n Der WAL-Sender ist ein weiterer Prozess, der auf dem Prim\u00e4rserver l\u00e4uft und daf\u00fcr zust\u00e4ndig ist, die WAL-Datens\u00e4tze an den Standby-Server zu senden, sobald sie erzeugt werden. Der WAL-Receiver speichert die WAL-Datens\u00e4tze in der WAL, als ob sie durch die Client-Aktivit\u00e4ten der lokal verbundenen Clients erstellt worden w\u00e4ren.<\/p>\n Sobald die WAL-Datens\u00e4tze die WAL-Segmentdateien erreicht haben, spielt der Standby-Server die WAL st\u00e4ndig neu ab, damit Prim\u00e4r- und Standby-Server auf dem neuesten Stand sind.<\/p>\n \u00a0<\/p>\n In diesem Abschnitt lernst du die gebr\u00e4uchlichen Modelle (Single-Master- und Multi-Master-Replikation), Typen (physische und logische Replikation) und Modi (synchron und asynchron) der PostgreSQL-Replikation n\u00e4her kennen.<\/p>\n Skalierbarkeit bedeutet, dass mehr Ressourcen\/Hardware zu den bestehenden Knoten hinzugef\u00fcgt werden, um die F\u00e4higkeit der Datenbank zu verbessern, mehr Daten zu speichern und zu verarbeiten, was horizontal und vertikal erreicht werden kann. Die PostgreSQL-Replikation ist ein Beispiel f\u00fcr horizontale Skalierbarkeit, die viel schwieriger zu implementieren ist als vertikale Skalierbarkeit. Wir k\u00f6nnen horizontale Skalierbarkeit haupts\u00e4chlich durch Single-Master-Replikation (SMR) und Multi-Master-Replikation (MMR) erreichen.<\/p>\n Bei der Single-Master-Replikation k\u00f6nnen Daten nur auf einem einzigen Knoten ge\u00e4ndert werden, und diese \u00c4nderungen werden auf einen oder mehrere Knoten repliziert. Die replizierten Tabellen in der Replikatdatenbank d\u00fcrfen keine \u00c4nderungen annehmen, au\u00dfer die vom Prim\u00e4rserver. Selbst wenn dies der Fall ist, werden die \u00c4nderungen nicht auf den Prim\u00e4rserver zur\u00fcckrepliziert.<\/p>\n In den meisten F\u00e4llen ist SMR f\u00fcr die Anwendung ausreichend, da es weniger kompliziert zu konfigurieren und zu verwalten ist und keine Konflikte auftreten k\u00f6nnen. Die Single-Master-Replikation ist au\u00dferdem unidirektional, da die Replikationsdaten nur in eine Richtung flie\u00dfen, n\u00e4mlich vom Prim\u00e4rserver zur Replikatdatenbank.<\/p>\n In manchen F\u00e4llen ist SMR allein nicht ausreichend und du musst MMR implementieren. MMR erm\u00f6glicht es, dass mehr als ein Knoten als prim\u00e4rer Knoten fungiert. \u00c4nderungen an Tabellenzeilen in mehr als einer bestimmten prim\u00e4ren Datenbank werden auf die entsprechenden Tabellen in jeder anderen prim\u00e4ren Datenbank repliziert. Bei diesem Modell werden oft Konfliktl\u00f6sungsschemata eingesetzt, um Probleme wie doppelte Prim\u00e4rschl\u00fcssel zu vermeiden.<\/p>\n Die Verwendung von MMR hat einige Vorteile, n\u00e4mlich<\/p>\n Der Nachteil von MMR ist jedoch die Komplexit\u00e4t und die Schwierigkeit, Konflikte aufzul\u00f6sen.<\/p>\n Verschiedene Branchen und Anwendungen bieten MMR-L\u00f6sungen an, da PostgreSQL sie nicht von Haus aus unterst\u00fctzt. Diese L\u00f6sungen k\u00f6nnen Open-Source<\/a>, kostenlos oder kostenpflichtig sein. Eine solche Erweiterung<\/a> ist die bidirektionale Replikation (BDR), die asynchron ist und auf der logischen Dekodierungsfunktion von PostgreSQL basiert.<\/p>\n Da die BDR-Anwendung Transaktionen auf anderen Knoten wiedergibt, kann die Wiedergabe fehlschlagen, wenn es einen Konflikt zwischen der angewendeten Transaktion und der Transaktion gibt, die auf dem empfangenden Knoten \u00fcbertragen wurde.<\/p>\n Es gibt zwei Arten der PostgreSQL-Replikation: die logische und die physische Replikation.<\/p>\n Eine einfache logische<\/em> Operation Die physische Replikation befasst sich normalerweise mit Dateien und Verzeichnissen. Sie wei\u00df nicht, was diese Dateien und Verzeichnisse darstellen. Diese Methoden werden verwendet, um eine vollst\u00e4ndige Kopie der gesamten Daten eines einzelnen Clusters, in der Regel auf einem anderen Rechner, zu erhalten. Sie erfolgen auf Dateisystem- oder Festplattenebene und verwenden exakte Blockadressen.<\/p>\n Bei der logischen Replikation werden Dateneinheiten und ihre \u00c4nderungen auf der Grundlage ihrer Replikationsidentit\u00e4t (normalerweise ein Prim\u00e4rschl\u00fcssel) reproduziert. Im Gegensatz zur physischen Replikation bezieht sie sich auf Datenbanken, Tabellen und DML-Operationen und wird auf der Ebene des Datenbank-Clusters durchgef\u00fchrt. Sie verwendet ein Publish-and-Subscribe-Modell<\/em>, bei dem ein oder mehrere Subscriber<\/em> eine oder mehrere Publikationen<\/em> auf einem Publisher-Node<\/em> abonnieren.<\/p>\n Der Replikationsprozess beginnt damit, dass ein Snapshot der Daten in der Publisher-Datenbank erstellt und dann auf den Subscriber kopiert wird. Die Subscriber ziehen die Daten aus den Publikationen, die sie abonniert haben, und k\u00f6nnen die Daten sp\u00e4ter erneut ver\u00f6ffentlichen, um eine kaskadierende Replikation oder komplexere Konfigurationen zu erm\u00f6glichen. Der Subscriber wendet die Daten in der gleichen Reihenfolge wie der Herausgeber an, so dass die transaktionale Konsistenz f\u00fcr die Publikationen innerhalb eines einzigen Abonnements gew\u00e4hrleistet ist, auch bekannt als transaktionale Replikation.<\/p>\n Die typischen Anwendungsf\u00e4lle f\u00fcr die logische Replikation sind:<\/p>\n Die Abonnentendatenbank verh\u00e4lt sich wie jede andere PostgreSQL-Instanz und kann als Publisher f\u00fcr andere Datenbanken verwendet werden, indem sie ihre Publikationen definiert.<\/p>\n Wenn der Abonnent von der Anwendung als schreibgesch\u00fctzt behandelt wird, gibt es keine Konflikte durch ein einzelnes Abonnement. Wenn jedoch andere Anwendungen oder andere Abonnenten auf dieselben Tabellen schreiben, kann es zu Konflikten kommen.<\/p>\n PostgreSQL unterst\u00fctzt beide Mechanismen gleichzeitig. Die logische Replikation erm\u00f6glicht eine fein abgestufte Kontrolle sowohl \u00fcber die Datenreplikation als auch \u00fcber die Sicherheit.<\/p>\n Es gibt haupts\u00e4chlich zwei Arten der PostgreSQL-Replikation: synchrone und asynchrone. Bei der synchronen Replikation k\u00f6nnen die Daten gleichzeitig auf den prim\u00e4ren und den sekund\u00e4ren Server geschrieben werden, w\u00e4hrend bei der asynchronen Replikation die Daten zuerst auf den Host geschrieben und dann auf den sekund\u00e4ren Server kopiert werden.<\/p>\n Bei der synchronen Replikation gelten die Transaktionen in der prim\u00e4ren Datenbank erst dann als abgeschlossen, wenn die \u00c4nderungen auf alle Replikate \u00fcbertragen wurden. Die Replikationsserver m\u00fcssen alle st\u00e4ndig verf\u00fcgbar sein, damit die Transaktionen auf dem Prim\u00e4rserver abgeschlossen werden k\u00f6nnen. Der synchrone Replikationsmodus wird in High-End-Transaktionsumgebungen verwendet, in denen eine sofortige Ausfallsicherung erforderlich ist.<\/p>\n Im asynchronen Modus k\u00f6nnen Transaktionen auf dem Prim\u00e4rserver f\u00fcr abgeschlossen erkl\u00e4rt werden, wenn die \u00c4nderungen nur auf dem Prim\u00e4rserver durchgef\u00fchrt wurden. Diese \u00c4nderungen werden dann zu einem sp\u00e4teren Zeitpunkt auf den Replikaten repliziert. Die Replikationsserver k\u00f6nnen f\u00fcr eine bestimmte Zeitspanne nicht synchronisiert sein, was als Replikationsverz\u00f6gerung bezeichnet wird. Im Falle eines Absturzes kann es zu Datenverlusten kommen, aber der Overhead, den die asynchrone Replikation verursacht, ist gering, so dass er in den meisten F\u00e4llen akzeptabel ist (der Host wird nicht \u00fcberlastet). Der Failover von der prim\u00e4ren Datenbank zur sekund\u00e4ren Datenbank dauert l\u00e4nger als die synchrone Replikation.<\/p>\n In diesem Abschnitt zeigen wir dir, wie du den PostgreSQL-Replikationsprozess auf einem Linux-Betriebssystem einrichtest. F\u00fcr dieses Beispiel verwenden wir Ubuntu 18.04 LTS und PostgreSQL 10.<\/p>\nWas ist PostgreSQL Replikation?<\/h2>\n
![\"Eine](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Was ist automatisches Failover?<\/h3>\n
Vorteile der PostgreSQL-Replikation<\/h2>\n
\n
Wie PostgreSQL-Replikation funktioniert<\/h2>\n
\n
Methode 1: Streaming<\/h3>\n
Konfiguration des prim\u00e4ren Knotens<\/h4>\n
Schritt 1: Initialisierung der Datenbank<\/h5>\n
initdb<\/code> verwenden. Anschlie\u00dfend kannst du mit dem folgenden Befehl einen neuen Benutzer mit Replikationsrechten anlegen:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nSchritt 2: Streaming-Eigenschaften konfigurieren<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code><\/strong>: Dieser Parameter wird f\u00fcr die Funktion pg_rewind<\/code> ben\u00f6tigt, die n\u00fctzlich ist, wenn der Standby-Server nicht mehr mit dem prim\u00e4ren Server synchronisiert ist.<\/li>\nwal_level<\/code><\/strong>: Mit diesem Parameter kannst du die PostgreSQL Streaming Replikation aktivieren. M\u00f6gliche Werte sind minimal<\/code>, replica<\/code> oder logical<\/code>.<\/li>\nmax_wal_size<\/code><\/strong>: Mit diesem Parameter kannst du die Gr\u00f6\u00dfe der WAL-Dateien angeben, die in den Logdateien aufbewahrt werden k\u00f6nnen.<\/li>\nhot_standby<\/code><\/strong>: Du kannst diesen Parameter f\u00fcr eine Read-On-Verbindung mit dem sekund\u00e4ren Server nutzen, wenn er auf ON gesetzt ist.<\/li>\nmax_wal_senders<\/code><\/strong>: Mit max_wal_senders<\/code> kannst du die maximale Anzahl der gleichzeitigen Verbindungen festlegen, die mit den Standby-Servern hergestellt werden k\u00f6nnen.<\/li>\n<\/ul>\nSchritt 3: Neuen Eintrag erstellen<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code>, sich zu verbinden und als Standby-Server zu fungieren, indem er die angegebene IP f\u00fcr die Replikation verwendet. Zum Beispiel:<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nStandby-Knoten konfigurieren<\/h4>\n
Schritt 1: Sichern des prim\u00e4ren Knotens<\/h5>\n
pg_basebackup<\/code> ein Backup des prim\u00e4ren Knotens. Diese dient als Startpunkt f\u00fcr den Standby-Knoten. Du kannst dieses Dienstprogramm mit der folgenden Syntax verwenden:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code><\/strong>: Damit kannst du den prim\u00e4ren Host angeben.<\/li>\n-D<\/code><\/strong>: Dieser Parameter gibt das Verzeichnis an, in dem du gerade arbeitest.<\/li>\n-C<\/code><\/strong>: Damit kannst du die Checkpoints setzen.<\/li>\n-X<\/code><\/strong>: Mit diesem Parameter kannst du die notwendigen Transaktionsprotokolldateien einbinden.<\/li>\n-W<\/code><\/strong>: Mit diesem Parameter kannst du den Benutzer zur Eingabe eines Passworts auffordern, bevor er sich mit der Datenbank verbindet.<\/li>\n<\/ul>\nSchritt 2: Replikationskonfigurationsdatei einrichten<\/h5>\n
-R<\/code> im Dienstprogramm pg_basebackup<\/code> verwendest.<\/p>\nstandby_mode = 'on'\n\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'\n\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n\n
primary_conninfo<\/code><\/strong>: Mit diesem Parameter kannst du eine Verbindung zwischen dem prim\u00e4ren und dem sekund\u00e4ren Server herstellen, indem du einen Verbindungsstring verwendest.<\/li>\nstandby_mode<\/code><\/strong>: Dieser Parameter kann bewirken, dass der prim\u00e4re Server als Standby-Server gestartet wird, wenn er eingeschaltet wird.<\/li>\nrecovery_target_timeline<\/code><\/strong>: Damit kannst du die Wiederherstellungszeit festlegen.<\/li>\n<\/ul>\n primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nSchritt 3: Neustart des Sekund\u00e4rservers<\/h5>\n
\n
Methode 2: Repliziertes Blockger\u00e4t<\/h3>\n
Methode 3: WAL<\/h3>\n
Log Shipping-basierte Replikation (Block Level)<\/h4>\n
Log Shipping-basierte Replikation (File Level)<\/h4>\n
Kontinuierliche WAL-Archivierung<\/h4>\n
pg_wal<\/code>, 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.<\/p>\nscp<\/code> nutzen, um die Datei an einen oder mehrere Speicherorte zu duplizieren, z. B. in ein NFS-Mount. Einmal archiviert, k\u00f6nnen die WAL-Segmentdateien genutzt werden, um die Datenbank zu einem beliebigen Zeitpunkt wiederherzustellen.<\/p>\n\n
Details zum WAL-Streaming-Protokoll<\/h4>\n
primary_conninfo<\/code> der recovery.conf<\/strong> angegeben sind, und verbindet sich \u00fcber eine TCP\/IP-Verbindung mit dem Prim\u00e4rserver.<\/p>\n![\"Ein](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elemente der PostgreSQL-Replikation<\/h2>\n
Modelle der PostgreSQL Datenbankreplikation<\/h3>\n
\n
Arten der PostgreSQL-Replikation<\/h3>\n
initdb<\/code> w\u00fcrde die physische Operation der Erstellung eines Basisverzeichnisses f\u00fcr einen Cluster ausf\u00fchren. Ebenso w\u00fcrde eine einfache logische<\/em> Operation CREATE DATABASE<\/code>\u00a0die physische<\/em> Operation der Erstellung eines Unterverzeichnisses im Basisverzeichnis durchf\u00fchren.<\/p>\n\n
Replikationsmodi<\/h3>\n
So richtest du die PostgreSQL-Replikation ein<\/h2>\n