12. Oktober 2026 · 1 Min. Lesezeit

Hochverfügbares PostGIS ist mehr als Replikation

Ein Replikat ist noch kein Failover-Konzept. Was für eine Geodatenbank, die laufen muss, wirklich nötig ist.

In diesem Artikel
  1. Replikation ist der Anfang
  2. Automatischer Failover braucht einen Schiedsrichter
  3. Backups, die wirklich zurückgespielt wurden
  4. Auch die Kartenschicht zählt
  5. Upgrades und Tests
  6. Zuerst die Zahlen festlegen

Ein zweiter Datenbankserver ist, wo die meisten anfangen. Dort endet Hochverfügbarkeit aber nicht.

Replikation ist der Anfang

Die PostgreSQL-Streaming-Replikation hält eine Kopie Ihrer PostGIS-Datenbank auf einem anderen Server. Das schützt vor dem Verlust einer Festplatte. Es schaltet die Anwendungen aber nicht von selbst auf die Kopie um, wenn der Primärserver ausfällt, und schützt nicht vor einem fehlerhaften DELETE, denn der Fehler wird mitrepliziert.

Automatischer Failover braucht einen Schiedsrichter

Jemand muss entscheiden, dass der Primärserver wirklich weg ist, genau ein Replikat befördern und alle anderen informieren. Schlecht gemacht entstehen zwei Primärserver mit Schreibzugriff, ein „Split Brain“, das viel schlimmer ist als ein Ausfall. Werkzeuge wie Patroni lösen das mit einem verteilten Konsensspeicher (etcd) und drei stimmberechtigten Mitgliedern, sodass eine Netzwerktrennung keine zwei Leader erzeugen kann. Anwendungen verbinden sich über einen Load Balancer oder eine virtuelle IP, die stets auf den aktuellen Primärserver zeigt.

Backups, die wirklich zurückgespielt wurden

Replikation und Backup lösen unterschiedliche Probleme. Nötig sind Point-in-Time-Recovery mit kontinuierlicher WAL-Archivierung (meist pgBackRest), eine externe Kopie und geplante Restore-Übungen. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Backup.

Auch die Kartenschicht zählt

Nutzer sehen nicht die Datenbank, sondern die Karte. Wir betreiben mehrere zustandslose GeoServer- oder MapProxy-Instanzen hinter einem Load Balancer, cachen Kacheln und sorgen dafür, dass eine langsame Abfrage nicht den ganzen Dienst lahmlegt.

Upgrades und Tests

Die meisten Ausfallzeiten sind geplant. Rolling Upgrades, an einer Kopie geübt, drücken sie nahe null. Vor dem Go-live gehen wir dann gezielt kaputt: Primärserver stoppen, Netzwerk trennen, Platte füllen und beobachten.

Zuerst die Zahlen festlegen

Wie viele Daten dürfen verloren gehen (RPO) und wie lange darf das System stehen (RTO)? Die Antworten bestimmen Architektur und Preis, daher sollte man sich vor der Werkzeugwahl darauf einigen.

Planen Sie ein geschäftskritisches GIS?

Erzählen Sie uns von Ihrem System. Das Erstgespräch ist kostenlos.