So optimieren Sie die logische PostgreSQL-Replikation

Die logische Replikation oder Pglogical ist ein WAL-basierter Replikationsmechanismus auf Tabellenebene, der die Daten bestimmter Tabellen zwischen zwei PostgreSQL-Instanzen repliziert. Es scheint eine Verwechslung zwischen „pglogical“ und „Logical Replication“ zu geben. Beide bieten die gleiche Art von Replikationsmechanismus mit einigen Unterschieden in Merkmalen und Fähigkeiten. Die logische Replikation wird in PostgreSQL-10 als integrierte Funktion eingeführt, im Gegensatz zu pglogical, das eine Erweiterung ist. „Pglogical“ mit fortlaufenden kontinuierlichen Entwicklungen bleibt die einzige Option zur Implementierung der logischen Replikation für Umgebungen, die PostgreSQL-Versionen vor 10 verwenden. Letztendlich werden alle Funktionen von pglogical Teil der logischen Replikation sein. Mit anderen Worten, aus pglogical (Erweiterung) wurde Logical Replication (integrierte Funktion). Der grundlegende Vorteil der logischen Replikation besteht darin, dass keine Erweiterungen installiert/erstellt werden müssen, was wiederum für Umgebungen von Vorteil ist, in denen die Installation von Erweiterungen eingeschränkt ist.

Dieser Blog konzentriert sich auf die Optimierung der logischen Replikation. Das bedeutet, dass die in diesem Blog hervorgehobenen Optimierungstipps und -techniken sowohl für die pglogische als auch für die logische Replikation gelten.

Die logische Replikation ist eine WAL-basierte Replikation, die die erste ihrer Art ist. Als DBA wäre dies im Vergleich zu anderen triggerbasierten Replikationslösungen ein viel zuverlässigerer und leistungsfähigerer Replikationsmechanismus. Die an den Tabellen der pglogical-Replikation vorgenommenen Änderungen werden in Echtzeit über WAL-Datensätze repliziert, was sie hocheffizient und unkompliziert macht. Alle anderen Replikationsmechanismen auf dem Markt basieren auf Auslösern, was zu Leistungs- und Wartungsproblemen führen kann. Mit der Einführung der logischen Replikation ist die Abhängigkeit von der Trigger-basierten Replikation fast verschwunden.

Es gibt andere Blogs, die ausführlich erklären, wie man die logische Replikation konfiguriert.

In diesem Blog liegt der Schwerpunkt auf der Optimierung der logischen Replikation.

Logische Replikation optimieren

Zunächst einmal ist das Verhalten der „Logischen Replikation“ der „Streaming-Replikation“ sehr ähnlich, der einzige Unterschied besteht darin, dass die Streaming-Replikation die gesamte Datenbank repliziert, während die Logische Replikation nur einzelne Tabellen repliziert. Bei der Auswahl spezifischer individueller Tabellen zum Replizieren müssen Faktoren/Herausforderungen vorhergesehen werden.

Werfen wir einen Blick auf Faktoren, die die logische Replikation beeinflussen.

Faktoren, die die Leistung der logischen Replikation beeinflussen

Die Optimierung der logischen Replikation ist wichtig, um sicherzustellen, dass Daten nahtlos und ohne Unterbrechungen repliziert werden. Es gibt Faktoren, die vor der Einrichtung vorhergesehen werden müssen. Werfen wir einen Blick auf sie:

• Der Datentyp, der in den zu replizierenden Tabellen gespeichert ist
• Wie transaktional aktiv sind die Tabellen (Teil der Replikation)
• Infrastrukturkapazität muss vorgesehen werden
• Die Parameterkonfiguration muss optimal erfolgen

Alle oben genannten Faktoren beeinflussen die logische Replikation stärker. Sehen wir sie uns im Detail an.

Logische PostgreSQL-Replikationsdatentypen

Es ist wichtig, die Art der in der Tabelle gespeicherten Daten zu verstehen. Wenn der Tabellenteil der Replikation große Text- oder Binärobjekte speichert und auf eine hohe Anzahl von Transaktionen trifft, kann sich die Replikation aufgrund der hohen Nutzung von Infrastrukturressourcen verlangsamen. Die Kapazität der Infrastruktur muss ausreichend sein, um eine solch komplexe und große Datenreplikation zu bewältigen.

Wie aktive Tabellen transaktional Teil der Replikation sind

Beim Replizieren hochgradig transaktional aktiver Tabellen kann die Replikation aufgrund von E/A-Leistungsproblemen, Deadlocks usw. bei der Synchronisierung hinterherhinken, was berücksichtigt werden muss. Dadurch sehen Produktionsdatenbankumgebungen möglicherweise nicht gesünder aus. Wenn die Anzahl der zu replizierenden Tabellen hoch ist und die Daten auf mehrere Standorte repliziert werden, kann es zu einer hohen CPU-Auslastung kommen und es sind mehr CPUs (oder CPU-Kerne) erforderlich.

Infrastrukturkapazität

Bevor Sie die logische Replikation als Lösung in Betracht ziehen, ist es wichtig sicherzustellen, dass die Infrastrukturkapazität der Datenbankserver ausreichend ist. Wenn eine große Anzahl von Tabellen repliziert wird, müssen genügend CPUs verfügbar sein, um die Replikationsaufgabe auszuführen.

Wenn Sie eine große Anzahl von Tabellen replizieren, sollten Sie sie in Gruppen aufteilen und parallel replizieren. Auch hier müssen mehrere CPUs für die Replikation verfügbar sein. Wenn die Datenänderungen an den replizierten Tabellen häufig und umfangreich sind, kann sich dies ebenfalls auf die Replikationsleistung auswirken.

Optimierungsparameter für die logische Replikation

Parameter, die für die Funktion der logischen Replikation konfiguriert sind, müssen optimal abgestimmt werden, um sicherzustellen, dass die Replikation nicht unterbrochen wird.

Lassen Sie uns zuerst einen Blick auf die Parameter werfen, die zur Konfiguration benötigt werden:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Max_wal_senders optimieren

max_wal_senders muss immer größer sein als die Anzahl der Replicas. Wenn die Daten auf mehrere Sites repliziert werden, kommen mehrere max_wal_sender ins Spiel. Daher ist es wichtig sicherzustellen, dass dieser Parameter auf eine optimale Zahl eingestellt ist.

Max_replication_slots optimieren

Im Allgemeinen werden alle Datenänderungen, die an den Tabellen auftreten, in WAL-Dateien in pg_xlog / pg_wal geschrieben, die als WAL-Datensätze bezeichnet werden. Der Wal-Sender-Prozess würde diese WAL-Datensätze (die zu den replizierten Tabellen gehören) aufnehmen und an die Replikate senden, und der wal_receiver-Prozess auf der Replikat-Site würde diese Änderungen am Abonnentenknoten anwenden.

Die WAL-Dateien werden bei jedem Checkpoint aus dem Speicherort pg_xlog/pg_wal entfernt. Wenn die WAL-Dateien entfernt werden, noch bevor die Änderungen auf den Abonnentenknoten angewendet werden, würde die Replikation abbrechen und hinterherhinken. Für den Fall, dass der Abonnentenknoten hinterherhinkt, würde ein Replikationsslot sicherstellen, dass alle WAL-Dateien, die der Abonnent benötigt, um mit dem Anbieter synchronisiert zu werden, beibehalten werden. Es wird empfohlen, für jeden Abonnentenknoten einen Replikationsslot zu konfigurieren.

Max_worker_processes optimieren

Es ist wichtig, dass eine optimale Anzahl von Worker-Prozessoren konfiguriert ist. Dies hängt davon ab, wie viele Prozesse ein Server maximal haben kann. Dies ist nur in Umgebungen mit mehreren CPUs möglich. Max_worker_processes stellt sicher, dass mehrere Prozesse gestartet werden, um die Arbeit schneller zu erledigen, indem mehrere CPU-Kerne verwendet werden. Beim Replizieren von Daten mithilfe der logischen Replikation kann dieser Parameter dabei helfen, mehrere Worker-Prozesse zu generieren, um die Daten schneller zu replizieren. Es gibt einen speziellen Parameter namens max_logical_worker_processes, der sicherstellt, dass mehrere Prozesse zum Kopieren der Daten verwendet werden.

Max_logical_worker_processes optimieren

Dieser Parameter gibt die maximale Anzahl logischer Worker-Prozesse an, die für die Replikation und Synchronisierung von Tabellendaten erforderlich sind. Dieser Wert wird von max_worker_processes übernommen, der höher sein sollte als dieser Parameterwert. Dieser Parameter ist sehr vorteilhaft, wenn Daten in Multi-CPU-Umgebungen an mehrere Standorte repliziert werden. Der Standardwert ist 4. Der Maximalwert hängt davon ab, wie viele Worker-Prozesse das System unterstützt.

Optimierung von max_sync_workers_per_subscription

Dieser Parameter gibt die maximale Anzahl von Synchronisierungsprozessen an, die pro Abonnement erforderlich sind. Der Synchronisierungsprozess findet während der anfänglichen Datensynchronisierung statt und um sicherzustellen, dass dies schneller erfolgt, kann dieser Parameter verwendet werden. Aktuell kann pro Tabelle nur ein Synchronisationsprozess konfiguriert werden, d.h. mehrere Tabellen können zunächst parallel synchronisiert werden. Der Standardwert ist 2. Dieser Wert wird aus dem Wert max_logical_worker_processes ausgewählt.

Dies sind die Parameter, die abgestimmt werden müssen, um sicherzustellen, dass die logische Replikation effizient und schneller ist. Die anderen Parameter, die sich ebenfalls auf die logische Replikation auswirken, lauten wie folgt.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Diese Parameter haben keine Auswirkung auf den Provider-Knoten.

Schlussfolgerung

Replikationsspezifische Tabellen sind eine häufige Anforderung, die in großen und komplexen Datenbanksystemen auftritt. Dies kann für Geschäftsberichts- oder Data-Warehousing-Zwecke sein. Als DBA glaube ich, dass Logical Replication aufgrund seiner einfachen Implementierung mit geringerer Komplexität für solche Zwecke hervorragend geeignet ist. Das Konfigurieren und Optimieren der logischen Replikation erfordert viel Planung, Architektur und Tests. Die Datenmenge, die in Echtzeit repliziert wird, muss bewertet werden, um sicherzustellen, dass ein effizientes und nahtloses Replikationssystem vorhanden ist. Abschließend sei gesagt, dass für Datenbanken, die in PostgreSQL-10 ausgeführt werden, die logische Replikation der richtige Weg ist, und für Datenbanken, die in den PostgreSQL-Versionen <10 ausgeführt werden, ist pglogical die Option.