Streaming Replication ist eines der top Features von PostgreSQL. Die Idee hinter Streaming Replication ist, das PostgreSQL Transaction Log (WAL) auf eine beliebige Anzahl von Slaves (Standby Server) zu replizieren und dort wieder einzuspielen, um eine binäre Kopie des Masters zu erzeugen, der als Read-Only Replikat verwendet werden kann.

In PostgreSQL kann Replikation auf zwei Arten erfolgen:

  • Synchrone Replikation
  • Asynchrone Replikation

Abhängig von Ihren Anforderungen können Sie flexibel entscheiden, welcher Modus für Sie zweckdienlicher ist.

Asynchrone Repliation in PostgreSQL

Wenn ein Server ausfällt und somit der schlimmstmögliche Fehlerfall eintritt, ist es eine gute Idee, eine Replikation zu haben. Glücklicherweise erlaubt es PostgreSQL, read-only Replikate einzurichten, die im Fall eines Datenbank Crashs sofort einspringen können, um zu übernehmen.

Replikate haben zahlreiche Vorteile:

  • Kontinuierliche Datensicherung
  • Automatisches Failover
  • Skalierung von read-only Workloads
  • Georedundanz

Asynchrone Replikation ist die „Standardmethode“, um in der PostgreSQL Welt Daten zu replizieren und um Setups abzusichern.
Der große Vorteil von asynchroner Replikation sind die Einfachheit, der geringe Overhead und die Zuverlässigkeit der Technologie. Asynchrone Replikation ist der ideale Mechanismus, um automatisches Failover zu implementieren.

Wie asynchrone Replikation funktioniert

Bei asynchroner Replikation erreichen die Daten die Standby Systeme NACH dem Commit auf dem Master. Es gibt also ein sehr kleines Zeitfenster, in dem Datenverlust passieren kann (üblicherweise geht es um weniger als eine Sekunde).

PostgreSQL Replication Asynchronous

Oft ist das absolut akzeptabel, weil asynchrone Replikation aufgrund des geringen Overheads sehr effizient ist und seltener, minimaler Datenverlust generell für viele Anwendung zu tolerieren ist.

Kaskadierte Repliation

In PostgreSQL kann die Replikation nicht nur vom Master zum Slave erfolgen. Es ist auch möglich, einen Slave wieder direkt von einem Slave abzuleiten. In diesem Fall spricht man von kaskadierter Replikation. Kaskadierung ist besonders sinnvollen, wenn Sie Ihr Setup geographisch verteilen wollen.

Ein Beispiel: >
Stellen Sie sich vor, Ihr Datenbankserver befindet sich in New York (USA) und wollen Replikate in Frankfurt, Stuttgart, Berlin und Aachen (Deutschland). Wenn alle Replikate direkt am Master in New York hängen, müssen Sie die Daten 4 mal über den Atlantik schicken. Alternativ dazu können Sie das Transaction Log (WAL) nach Frankfurt replizieren und dort nach Stuttgart, Berlin und Aachen weiterverteilen. Das spart Bandbreite.

Synchrone Replikation in PostgreSQL

Wenn Sie das geringe Risiko eines Datenverlusts bei asynchroner Replikation nicht tragen wollen oder tragen können, können Sie auf synchrone Replikation umschalten. Der Vorteil ist: Eine Transaktion gilt erst, wenn Sie von einem Replikat bestätigt ist. Die Applikation kann sich also darauf verlassen, dass die Daten mindestens auf 2 Servern liegen.

Synchrone Replikation garantiert das größtmögliche Maß an Sicherheit und vermeidet Datenverlust im Crash Fall.

Wie synchrone Replikation funktioniert

Synchrone Replikation vermeidet Datenverlust und garantiert Redundanz.

PostgreSQL Replication Synchronous

Eine Transaktion muss von mindestens einem Slave bestätigt werden bevor der Schreibzugang akzeptiert wird.

Moderne Features: Quorum COMMIT

Mit der Einführung von PostgreSQL 10.0 steht noch eine weitere fortgeschrittene Funktionalität zur Verfügung: Sogenannte Quorum Commits. Die Idee ist, dass man sich aussuchen kann, wieviele Server eine Transaktion bestätigen müssen bevor Sie gilt. Es ist also möglich, sich nicht mehr nur auf einen Slave zu verlassen sondern gleich eine ganze Reihe von Servern zu verwenden, um eine Transaktion zu bestätigen.

FIRST num_sync (standby_name [, …])
ANY num_sync (standby_name [, …])

Gönnen Sie Ihren Administratoren und Entwicklern mehr Flexibilität. Wir helfen Ihnen dabei.

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!