Ist Ihre Datenbank auf mehreren Standorten verteilt oder haben Sie Kunden, die auf der ganzen Welt operieren? Vielleicht arbeiten Sie in mehreren Zeitzonen? Wenn die Antwort auf diese Fragen „ja“ ist, wäre es vielleicht eine gute Idee, über asynchrone Multimaster Replikation nachzudenken.

Hinweis: PostgreSQL Multimaster Replikation wird über ein Tool namens BDR realisiert, dass von Cybertec voll supported wird (24×7 Support für PostgreSQL und BDR).

Anwendungsfälle für PostgreSQL Multimaster Replication

Normale Streaming Replikation (Single Master) ist für einfache Hochverfügbarkeitslösungen auf alle Fälle die bevorzugte Methode. Wenn Sie jedoch Ihre Daten geographisch verteilen wollen, ist Multimaster Replikation definitiv eine Option und sollte ins Auge gefasst werden. Speziell wenn über unzuverlässige Verbindungen repliziert wird oder wenn mit langen Ausfallszeiten zu rechnen ist, kann Multimaster Replikation in PostgreSQL seine Stärken ausspielen.

Ein typischer Anwendungsfall:

Stellen Sie sich vor, Ihre Firma verkauft Produkte in Berlin (Deutschland) und in Seattle (USA) – das Management in London will aber Daten von allen Standorten sehen (sogar dann, wenn die Netzwerkverbindung nicht verfügbar ist). Genau das ist der ideale Anwendungsfall für Multimaster Replikation.

PostgreSQL Replication Multimaster

Daten werden von allen Standorten auf alle anderen Standorte repliziert und PostgreSQL stellt so sicher, dass am Ende des Tages jeder Server alle Daten hat.
Replikation kann mit BDR aber auch sehr selektiv passieren: Es ist möglich nur einzelne Tabellen oder einzelne Schemata bidirektional zu übertragen. Oft ist es nicht nötig, dass die ganze Instanz übertragen wird und es kann Sinn machen, nur einzelne Teile synchron zu halten.

Wie Multimaster Replikation funktioniert

In PostgreSQL basiert Multimaster Replikation (BDR) auf einem Feature namens „Logical Decoding“. Die Idee dahinter ist, den Strom des Transaction Logs zu analysieren und daraus wieder lesbare Daten zu generieren. BDR erzeugt aus dem WAL wieder SQL, das dann im Cluster verteilt werden und in alle anderen Database Nodes eingespielt werden kann.

Konflikte bei der Replikation managen

Wenn Sie sich für asynchrone Multimaster Replikation (BDR) entschieden haben, ist es wichtig, auch an Replikationskonflikte zu denken. Oft passiert es, dass die selben oder ähnliche Änderungen auf die selben Daten von zwei Standorten aus passieren. In diesem Fall kann ein Konflikt eintreten, den BDR zu lösen hat – es kann also passieren, dass eine Transaktion NACH einem COMMIT wieder zurückgerollt werden muss.

Wir geben zu bedenken, dass Konflikte bei jeder asynchronen Replikationstechnik auftreten können und es sich um keine Besonderheit von PostgreSQL oder BDR handelt.

PostgreSQL Replication Connection and API URL

Besonders Entwickler sollten sich darauf einstellen, dass schreibende Transaktionen im Konfliktfall möglicherweise zurückgerollt werden. Für manche Entwickler ist das eine unliebsame Überraschung.

BDR kann Konflikte auf verschiedene Art handhaben: Neben einer Default Policy ist es auch möglich, eigene „conflict handlers“ zu definieren, die es erlauben, eine eigene Strategie für das Konfliktmanagement zu definieren. Wenn Sie mehr über Konfliktmanagement wissen wollen, finden Sie hier eine kleine Anleitung.

Wir helfen gerne bei der Implementierung von eigenen Conflict Handlers.

„Divergence Konflikte“ verstehen

Multimaster Replikation ist ein wertvolles Tool, um Daten im Cluster zu verteilen. Leider können jedoch nicht immer alle Konflikte gelöst werden. Es kann also zu sogenannten „Divergence Konflikten“ kommen, die dazu führen, dass der Inhalt der einzelnen Knoten im Cluster nicht mehr ident ist – die einzelnen Server können also auseinander laufen.

Wenn es Ihnen also nicht um geographisch verteilte Daten geht, sondern das Ziel Hochverfügbarkeit ist, raten wir, sich mit Patroni zu beschäftigen.

Mehr über Patroni

Professionelle Hilfe

Kontaktieren Sie uns noch heute, um ihr persönliches Angebot von Cybertec zu erhalten. Wir bieten eine zeitnahe Lieferung, professionelle Arbeit und über 17 Jahre PostgreSQL Erfahrung.

Kontaktieren Sie uns!