Das Replizieren der in Ihrer Datenbank gespeicherten Informationen ist unerlässlich, um Daten zu verteilen und sicherzustellen, dass Sie über ein Backup verfügen, das für die Notfallwiederherstellung verwendet werden kann, falls etwas schief geht.
Die PostgreSQL-Replikation gibt es in zwei Formen, und beide haben ihre Nischenanwendungen. Wenn Sie verstehen, wie Sie eine oder beide dieser Datenreplikationsmethoden anwenden, können Sie Ihre Datenverteilungsprozesse optimieren. Das Letzte, was Sie wollen, ist, wichtige Arbeit zu verlieren, die Sie an einer Datenbank geleistet haben.
Werfen wir einen Blick auf die Vor- und Nachteile und Anwendungsfälle der Streaming-Replikation und der Logik in PostgreSQL.
Datenreplikation in PostgreSQL definieren
Wenn Sie bereits wissen, was Datenreplikation ist, können Sie fortfahren und zum nächsten Abschnitt hinunterscrollen. Aber für den Fall, dass Datenbank-Engineering neu für Sie ist, möchten wir schnell die Grundlage schaffen.
Wie der Name schon sagt, ist die Replikation der Prozess des häufigen Kopierens von Daten von einer Datenbank auf einem Computerserver in eine andere Datenbank auf einem anderen Server, sodass alle Benutzer Zugriff auf die gleiche Informationsebene haben. In der Datenverarbeitung wird die Replikation verwendet, um Fehler in einem digitalen System zu beseitigen.
Replikation eliminiert Datensilos, schützt wertvolle Informationen und optimiert die Entwicklung.
In PostgreSQL gibt es zwei Optionen für die Replikation:logische Replikation und Streaming-Replikation. Diese Methoden eignen sich hervorragend für verschiedene Anwendungsfälle, und als Entwickler neigen Sie möglicherweise eher dazu, eine über der anderen zu verwenden. Es ist jedoch gut zu verstehen, wie man beide verwendet, damit Sie entscheiden können, welche Sie in verschiedenen Szenarien anwenden möchten.
Logische Replikation in PostgreSQL
Die Streaming-Replikation wurde zur Verwendung mit PostgreSQL v10.0 eingeführt. Die logische Replikation funktioniert durch Kopieren/Replizieren von Datenobjekten und deren Änderungen basierend auf ihrer Replikationsidentität.
In vielen Fällen ist die Identität der Daten ein Primärschlüssel. In PostgreSQL gibt es Benutzern eine feinkörnige Kontrolle über die replizierten Daten und die Informationssicherheit.
Der Begriff logisch wird verwendet, um sie von der physischen Replikation zu unterscheiden, die eine Byte-für-Byte-Replikation und exakte Blockadressen verwendet. Lesen Sie hier mehr in der offiziellen PostgreSQL-Dokumentation.
Durch ein Publish-and-Subscribe-Modell ermöglicht es einem oder mehreren Abonnenten, eine oder mehrere Veröffentlichungen auf einem Publisher-Knoten zu abonnieren. Die Abonnenten können Informationen aus den Veröffentlichungen abrufen und die Daten für eine kaskadierende Replikation oder eine komplexere Konfiguration erneut veröffentlichen.
Die logische Datenreplikation kann auch in Form einer Transaktionsreplikation erfolgen. Wenn der Techniker eine Tabelle kopieren möchte, kann er diese Replikationsmethode verwenden, um einen Schnappschuss der Daten auf der Seite des Herausgebers zu erstellen und ihn an die Datenbank des Abonnenten zu senden.
Wenn die Abonnenten Änderungen an den Originaldaten vornehmen, erhält die Herausgeberdatenbank Aktualisierungen in Echtzeit. Um die Transaktionskonsistenz in Veröffentlichungen mit einem einzigen Abonnement sicherzustellen, muss der Abonnent die Daten in derselben Reihenfolge wie der Herausgeber anwenden.
Vorteile der logischen Replikation in PostgreSQL
Die logische Replikation ermöglicht es Benutzern, einen Zielserver für Schreibvorgänge zu verwenden, und ermöglicht Entwicklern, unterschiedliche Indizes und Sicherheitsdefinitionen zu verwenden. Dies bietet eine verbesserte Flexibilität für die Übertragung von Daten zwischen Herausgebern und Abonnenten.
Versionsübergreifende Unterstützung
Darüber hinaus bietet es Unterstützung für verschiedene Versionen und kann zwischen verschiedenen Versionen von PostgreSQL eingestellt werden. Es bietet auch eine ereignisbasierte Filterung. Publikationen können mehrere Abonnements haben, was es einfach macht, Daten über ein breites Netzwerk zu teilen.
Mindestlast des Servers
Im Vergleich zu triggerbasierten Lösungen hat es eine minimale Serverlast und bietet gleichzeitig Speicherflexibilität durch die Replikation kleinerer Sätze. Wie oben erwähnt, kann die logische Datenreplikation sogar Daten kopieren, die in partitionierten Basistabellen enthalten sind.
Es ist auch wichtig zu erwähnen, dass die logische Datenreplikation eine Datentransformation bereits während der Einrichtung ermöglicht und ein paralleles Streaming über Publisher hinweg ermöglicht.
Nachteile der logischen Replikation in PostgreSQL
Die logische Replikation kopiert keine Sequenzen, große Objekte, materialisierte Ansichten, Partitionsstammtabellen und fremde Tabellen.
In PostgreSQL wird die logische Datenreplikation nur von DML-Vorgängen unterstützt. Entwickler können DDL oder Truncate nicht verwenden, und das Schema muss vorher definiert werden. Außerdem unterstützt es keine gegenseitige (bidirektionale) Replikation.
Wenn Benutzer auf Konflikte mit Einschränkungen für replizierte Daten in einer Tabelle stoßen, wird die Replikation beendet. Die Replikation kann nur fortgesetzt werden, wenn die Ursache des Konflikts behoben ist.
Ein unbeabsichtigter Konflikt kann die Dynamik Ihres Teams stoppen, daher müssen Sie verstehen, wie Sie Probleme schnell lösen können.
Wenn der Konflikt nicht schnell behoben wird, friert der Replikationsslot in seinem aktuellen Zustand ein, der Publisher-Knoten beginnt, Write-Ahead-Protokolle (WALs) zu sammeln, und dem Knoten wird schließlich der Speicherplatz ausgehen.
Anwendungsfälle für die logische Replikation in PostgreSQL
Viele Ingenieure verwenden die logische Replikation für:
- Verteilen von Änderungen innerhalb einer einzelnen Datenbank oder Datenbankteilmenge an Abonnenten in Echtzeit
- Zusammenführung mehrerer Datenbanken zu einer zentralen Datenbank (häufig für Analysezwecke)
- Erstellen von Replikationen über verschiedene Versionen von PostgreSQL hinweg
- Bereitstellen von Replikationen zwischen PostgreSQL-Instanzen auf verschiedenen Plattformen, z. B. von Linux zu Windows
- Replizierte Daten mit anderen Benutzern oder Gruppen teilen
- Verteilen einer Teilmenge einer Datenbank zwischen mehreren Datenbanken
Streaming-Replikation in PostgreSQL
Die Streaming-Replikation wurde zur Verwendung mit PostgreSQL 9.0 eingeführt. Der Prozess sendet WAL-Dateien (Write-Ahead Logging) von einem Master- oder primären Datenbankserver an eine Replikat- oder Empfangsdatenbank und wendet sie an. Die WALs werden zur Replikation und zur Sicherstellung der Datenintegrität verwendet.
Funktionsweise der Streaming-Replikation
Die Streaming-Replikation dient dazu, die Lücke zwischen Datenübertragungen zu schließen, die dem dateibasierten Protokollversand innewohnt, der wartet, bis eine WAL die maximale Kapazität zum Versenden von Daten erreicht.
Durch das Streamen von WAL-Einträgen streamen Datenbankserver WAL-Einträge in Blöcken, um die Daten zu synchronisieren. Der Standby-Server stellt eine Verbindung zum Replikat her und empfängt die WAL-Blöcke, sobald sie gesendet werden.
Bei der Streaming-Replikation muss der Benutzer entscheiden, ob er eine asynchrone oder eine synchrone Replikation einrichten möchte. Wenn die Streaming-Replikation anfänglich bereitgestellt wird, wird standardmäßig die asynchrone Replikation verwendet.
Dies weist darauf hin, dass es eine Verzögerung zwischen der anfänglichen Änderung auf dem primären Server und der Widerspiegelung dieser Änderung auf dem Replikat gibt. Die Asynchronisierung öffnet die Tür für potenziellen Datenverlust, wenn der Master abstürzt, bevor Änderungen kopiert werden, oder wenn die Kopie so nicht mit dem Original synchronisiert ist, dass sie bereits relevante Daten verworfen hat, um Änderungen vorzunehmen.
Die synchrone Replikation ist eine viel sicherere Option, da sie Änderungen in Echtzeit vornimmt. Die Übertragung vom Master zum Replikat gilt als unvollständig, bis beide Server die Informationen überprüft haben. Sobald die Datenänderungen bestätigt sind, wird die Übertragung auf den WALs beider Server aufgezeichnet.
Unabhängig davon, ob Sie asynchrone oder synchrone Replikation verwenden, müssen die Replikate über eine Netzwerkverbindung mit dem Master verbunden sein. Darüber hinaus ist es wichtig, dass die Benutzer Zugriffsrechte für die WAL-Streams des Replikats einrichten, damit die Informationen nicht kompromittiert werden.
Vorteile der Streaming-Replikation in PostgreSQL
Einer der wichtigsten Vorteile der Verwendung von Streaming-Replikation besteht darin, dass Daten nur verloren gehen können, wenn sowohl der primäre als auch der empfangende Server gleichzeitig abstürzen. Wenn Sie wichtige Informationen weitergeben, garantiert die Streaming-Replikation so gut wie, dass eine Kopie Ihrer Arbeit gespeichert wird.
Benutzer können mehr als einen Standby-Server mit dem primären Server verbinden, und die Protokolle werden vom primären zu jedem der verbundenen Standby-Server gestreamt. Wenn eines der Replikate verzögert wird oder die Verbindung getrennt wird, wird das Streaming zu den anderen Replikaten fortgesetzt.
Das Einrichten des Protokollversands durch Streaming-Replikation beeinträchtigt nichts, was der Benutzer derzeit in der primären Datenbank ausführt. Wenn der primäre Datenserver heruntergefahren werden muss, wartet er, bis die aktualisierten Datensätze an die Replik gesendet wurden, bevor er heruntergefahren wird.
Nachteile der Streaming-Replikation in PostgreSQL
Die Streaming-Replikation kopiert keine Informationen in eine andere Version oder Architektur, ändert die Informationen der Standby-Server und bietet keine granulare Replikation.
Insbesondere bei der asynchronen Streaming-Datenreplikation können ältere WAL-Dateien, die noch nicht auf das Replikat kopiert wurden, recycelt werden, wenn der Benutzer Änderungen am Master vornimmt. Um sicherzustellen, dass wichtige Dateien nicht verloren gehen, kann der Benutzer wal_keep_segments auf einen höheren Wert setzen.
Ohne die für die Replikationsserver eingerichteten Anmeldeinformationen für die Benutzerauthentifizierung können vertrauliche Daten leicht extrahiert werden. Damit Aktualisierungen in Echtzeit zwischen dem Master und dem Replikat erfolgen, muss der Benutzer die Replikationsmethode von der standardmäßigen asynchronen Replikation in die synchrone Replikation ändern.
Anwendungsfälle für die Streaming-Replikation in PostgreSQL
Viele Techniker verwenden die Streaming-Replikation für:
- Erstellen eines Backups für ihre primäre Datenbank im Falle eines Serverausfalls oder Datenverlusts
- Förderung einer Hochverfügbarkeitslösung mit möglichst geringer Replikationsverzögerung
- Große Abfragen entladen, um das primäre System etwas zu entlasten
- Verteilen von Datenbank-Workloads auf mehrere Computer, insbesondere für schreibgeschützte Formate
Was steht für die Zukunft auf dem Programm?
Die PostgreSQL Global Development Group kündigte die Veröffentlichung von PostgreSQL 14 am 30. September 2021 an. Die neue Version wurde mit Upgrades sowohl für das Streaming als auch für logische Replikationen über die Plattform geladen.
Für die Streaming-Replikation ermöglicht Version 14 den Benutzern Folgendes:
- Setzen Sie den Serverparameter
log_recovery_conflict_waitsum lange Wartezeiten bei Wiederherstellungskonflikten automatisch zu melden - Unterbrechen Sie die Wiederherstellung auf einem Hot-Standby-Server, wenn Sie die Parameter auf einem primären Server ändern (anstatt den Standby-Server sofort herunterzufahren)
- Verwenden Sie die Funktion
pg_get_wal_replay_pause_state()um den Wiederherstellungsstatus detaillierter zu melden - Geben Sie einen schreibgeschützten Serverparameter
in_hot_standbyan - Schnelles Abschneiden kleiner Tabellen während der Wiederherstellung auf Clustern mit einer großen Anzahl gemeinsam genutzter Puffer
- Dateisystemsynchronisierung zu Beginn der Wiederherstellung nach einem Absturz über Linux zulassen
- Verwenden Sie die Funktion
pg_xact_commit_timestamp_origin()bei einer bestimmten Transaktion, um den Commit-Zeitstempel und den Replikationsursprung zurückzugeben - Verwenden Sie die Funktion
pg_last_committed_xact()um den Replikationsursprung zum zurückgegebenen Datensatz hinzuzufügen - Verwenden Sie Standardfunktionsberechtigungskontrollen, um Replikationsursprungsfunktionen zu ändern (der Standard beschränkt den Zugriff immer noch auf die Superuser)
Für die logische Replikation ermöglicht Version 14 den Benutzern Folgendes:
- Streamen Sie mit der logischen Replikations-API lange laufende Transaktionen an Abonnenten
- Mehrere Transaktionen während Tabellenreplikationen zulassen
- Generieren Sie sofortige WAL-Log-Untertransaktionen und XID-Verknüpfungen auf oberster Ebene
- Verwenden Sie die Funktion
pg_create_logical_replication_slot()um logische Dekodierungs-APIs für Zwei-Phasen-Commits zu verbessern - Fügen Sie während der Befehlsausführung Cache-Invalidierungsmeldungen zur WAL hinzu, um ein logisches Streaming laufender Transaktionen zu ermöglichen
- Steuern Sie, welche logischen Dekodierungsnachrichten an den Replikationsstrom gesendet werden
- Verwenden Sie den binären Übertragungsmodus für schnellere Replikationen
- Entschlüsselung nach XID filtern
PostgreSQL arbeitet bereits an Version 15, die im dritten Quartal 2022 veröffentlicht werden soll. Eines der Probleme in Bezug auf die Replikation, die in der neuesten Version behoben werden sollen, ist die Verhinderung der Verwendung von Variablen, die von der Serverumgebung geerbt wurden, bei der Streaming-Replikation. Da sich jedoch immer mehr Benutzer an Version 14 gewöhnen, wird PostgreSQL wahrscheinlich weitere Aufgaben zur Verbesserung der Replikationsfunktionen hinzufügen.
Ein schneller Vergleich der PostgreSQL-Replikation:Logische vs. Streaming-Replikation
| Logische Replikation | Streaming-Replikation | |
|---|---|---|
| Modell | Publisher an Abonnent | Master to replik |
| Transaktionsreplikation | Ja | Nein |
| Lücken in der Replikation | Ein Konflikt stoppt die Replikation | Asynchron – kann eine Verzögerung zwischen der Datenübertragung zwischen dem primären und dem Replikat verursachen; synchron – Daten gehen nur verloren, wenn alle verbundenen Server gleichzeitig abstürzen |
| Replikation über verschiedene Plattformen oder PostgreSQL-Versionen hinweg | Ja | Nein |
| Sicherheit | Der Datenzugriff ist auf Abonnenten beschränkt | Zugriffsdaten müssen eingerichtet werden, um die Datensicherheit zu gewährleisten |
| Größe der Replikationen | Besser für granulare Replikation | Besser für groß angelegte Replikationen |
| Besonders nützlich für | Mehrere Systeme in einer Datenbank zusammenführen | Erstellen einer Sicherungsdatenbank |
Schlussfolgerung
Wir hoffen, dass dieser Leitfaden beim Einrichten Ihrer Replikationsfunktionen hilfreich ist. Wenn Sie Fragen haben oder etwas anderes darüber wissen möchten, wie ScaleGrid Ihnen bei Ihren PostgreSQL-Bereitstellungen helfen kann, wenden Sie sich an einen unserer vielen Datenbankexperten.
|
