Datenbank-Hochverfügbarkeit: Oracle und PostgreSQL im Vergleich
Der Trend von kommerziellen Datenbanken hin zu Open-Source-Lösungen zu wechseln, hat in den vergangenen Monaten nochmal deutlich an Fahrt aufgenommen. Das kann kaum jemand noch leugnen oder ignorieren. Es ist sogar immer häufiger auffällig, dass Jahrzehnte alte Datenbanksysteme, wie z. B. PostgreSQL und MySQL, gerne im gleichen Atemzug mit anderen modernen und neuen Technologien genannt werden. Die Ursachen für diesen Trend sind sehr vielfältig, aber die Lizenzpolitik von Oracle ist hier ein auffällig häufig genannter Grund.
Für eine Migration von Oracle auf eine alternative Datenbank ist wegen technischer Nähen PostgreSQL eine sinnvolle Wahl. Um jedoch wirklich im professionellen Umfeld tauglich zu sein, muss auch hier eine gewisse Ausfallsicherheit gewährleistet werden. Oracle hat eine umfangreiche Auswahl an etablierten Features. Mit diesem Artikel soll beschrieben werden, wie PostgreSQL diesbezüglich funktional aufgestellt ist, wie die Praxistauglichkeit aussieht und wo die Stärken und Schwächen gegenüber Oracle sind.
In der Vergangenheit war das Thema Hochverfügbarkeit in der Entwicklung von PostgreSQL nicht hoch priorisiert. Schließlich gab es bereits genug externe Lösungen, die entweder auf Betriebssystemebene, mit Software von Drittanbietern oder durch Redundanzen im Storage die Verfügbarkeit der Datenbank sichern sollten. Die Philosophie war, dass die Datenbanksoftware sich auf ihre eigene Aufgabe konzentrieren soll. Aus diesen Gründen war in dieser Zeit ein Failover-Cluster das Mittel der Wahl, um PostgreSQL-Datenbanken genau wie alle anderen Dienste vor dem Ausfall von Servern zu schützen. Es bestand in der Regel eine Abhängigkeit von zusätzlichen Lösungen, um im Fehlerfall die Datenbank automatisch auf einem anderen Server anzubinden und hochzufahren. Die Open-Source-Lösung Pacemaker von Cluster Labs ist eins der bekanntesten Beispiele. Eine vergleichbare Lösung von Oracle gab es mit dem Feature Failsafe für Windows Server Cluster, welches aber ab Version 19c nicht mehr weiter gepflegt wird.
Sauber konfiguriert und getestet ist dies durchaus eine valide Lösung. Ein Problem war und ist hierbei jedoch, dass lediglich der Ausfall der Serverknoten abgesichert wurde und der eigentliche Datenbestand nicht gegen Verlust oder Ausfälle geschützt war. Backups sind zwar obligatorisch, der Restore kann aber durchaus zu langer Downtime führen, die für hochverfügbare Systeme nicht akzeptabel ist. Zwischenzeitliche Ansätze mit Replikaten auf Filesystem-Basis, wie z. B. mit der Lösung Distributed Replicated Block Device (DRBD) für Linux, hatten sich in der Praxis mit sensiblen Datenbanksystemen, bei denen Konsistenz essenziell ist, häufig als zu korruptionsanfällig oder instabil erwiesen.
Mit den wachsenden Anforderungen der heutigen Zeit und zweifellos auch mit der Nachfrage von PostgreSQL im Enterprise-Segment wurden die Prioritäten bei der Entwicklung erfreulicherweise im vergangenen Jahrzehnt deutlich angepasst. Dies hat dazu geführt, dass insbesondere zuletzt viele Features implementiert wurden, die den Anforderungen für den Einsatz in großen und kritischen Umgebungen genügen können.
Oracle Maximum Availability Architecture
Oracle bietet als Marktführer der Branche selbstverständlich ein komplettes, umfangreiches und voll integriertes Lösungsangebot zum Thema Hochverfügbarkeit. Mit der Maximum Availability Architecture (MAA) wurde hierzu eine Art Best Practice in mehreren Abstufungen dokumentiert und veröffentlicht, um die angebotenen Technologien für Hochverfügbarkeit von Datenbanken je nach Anforderung einordnen zu können. Unterteilt in Bronze, Silber, Gold und Platin werden die Lösungen aufeinander aufbauend immer kritischeren Bedingungen gerecht. In der offiziellen Oracle-Dokumentation im Technologie-Netzwerk werden die Unterteilungen umfangreich beschrieben und illustriert [1].
Initial soll beim Bronze-Standard der Einsatz eines Backups mit Oracle Recovery Manager (RMAN) sowohl lokal als auch remote in einer anderen Lokation die Grundlage für die Verfügbarkeit sein. Es werden dabei weniger kritische Systeme adressiert, wie z. B. Test- oder Entwicklungsumgebungen. Leider hört auf dieser Ebene auch schon das Lösungsangebot auf, das Oracle für die Standard Edition 2 (SE2) Lizenz ab Version 19c anbietet. Sämtliche ab jetzt genannten Features und Funktionalitäten sind entweder Teile oder zusätzliche Optionen der etwas kostspieligeren Enterprise-Edition-(EE)-Lizenz. Sollte also der hochverfügbare Einsatz von SE2-lizenzierten Datenbanken gewährleistet werden, müssen entweder Lösungen von Drittherstellern genutzt oder auf in der MAA nicht direkt suggerierte Features zurückgegriffen werden. Es ist nach wie vor möglich, mit der Grid Infrastructure die Datenbank wie im Failover Cluster zu betreiben oder mit der kürzlich gelockerten Multitenant-Funktionalität auch für SE2 auf Refreshable Pluggable Databases zurückzugreifen.
Als nächste Stufe wird beim Silber-Standard der Real Application Cluster (RAC) eingeführt. Damit wird die Verfügbarkeit des Dienstes durch redundante Serverknoten sichergestellt. Die Daten selbst sind aber nach wie vor lediglich durch ein Backup gesichert.
Erst mit dem Gold-Standard wird durch eine Replikation mit Oracle Data Guard in ein anderes Rechenzentrum eine Redundanz mit einer StandBy-Datenbank hinzugefügt, um somit auch bei Fehlern oder Ausfällen auf Datenebene mit möglichst geringer Downtime wieder betriebsfähig zu sein.
Es wird häufig kontrovers diskutiert, ob die beiden letzten Standards in dieser Reihenfolge sinnvoll sind und nicht doch zuerst der Einsatz von Data Guard in Betracht gezogen werden sollte, bevor die Serverknoten mit RAC skaliert werden. Es handelt sich hierbei aber auch nur um eine unabhängige Empfehlung von Oracle und nicht um eine strenge Vorgabe.
Als finale Ausbaustufe wird im Platin-Standard für absolut hochkritische Systeme noch bidirektional mit Oracle Golden Gate über unterschiedliche Rechenzentren hinweg repliziert.
Zusammengefasst hat die MAA gezeigt, dass Oracle für alle Disziplinen eine passende Lösung im Portfolio hat. Für die Verfügbarkeit des Dienstes sorgt ein RAC durch redundante Knoten und die Sicherung der Daten werden initial durch Backups und zur schnellen Wiederverfügbarkeit mit Replikation gewährleistet. Wie stellt sich PostgreSQL entsprechend auf?
Stand-by-Datenbanken
Das Grundkonzept von Stand-by-Datenbanken existiert sowohl bei Oracle als auch bei PostgreSQL schon verhältnismäßig lange. Oracle hat als Vorreiter ca. 1996 mit der Version 7.3 hierzu die ersten Grundlagen gelegt – wenn auch noch manuell umgesetzt. Später im Jahr 1999 brachte die Version 8i die ersten wirklich verwaltbaren Stand-by-Datenbanken, die weitere zwei Jahre später mit der Version 9i auch als vollwertiges Feature Data Guard für die Enterprise-Edition-Lizenz eingeführt wurden.
Heute bietet Data Guard alles, was zu einem kompromisslosen Disaster-Recovery-Konzept mit Stand-by-Datenbanken gehört. Neben einer möglichen Wahl zwischen physikalischer datenblock-basierender oder logischer SQL-basierender Replikation kann auch über konfigurierbare Protection Modes verschiedene Betriebsarten die Replikation in Hinsicht auf Sicherheit, Performance oder Verfügbarkeit gesteuert werden.
Auch eine Automatisierung für eigenständig ausgeführte Failover nach definierten Bedingungen ist mit der Fast-Start-Failover-Funktionalität möglich. Für die Bedienung dient als kleinster gemeinsamer Nenner das logisch aufgebaute und integrierte Broker Command Line Interface (DGMGRL). Die Integration in Oracle Enterprise Manager Cloud Control ist selbstverständlich auch möglich. Um die Stand-by-Datenbank lesbar z. B. für Reporting-Zwecke nutzen zu können, bietet Oracle mit Active Data Guard eine zusätzlich zu lizensierende Option an, die diese Möglichkeit unterstützt.
Bei PostgreSQL hat sich das Konzept von Stand-by-Datenbanken erst etwas später mit der Version 9.0 im Jahr 2010 bei der Einführung des Features Streaming Replication wirklich ernstzunehmend durchgesetzt. In den Jahren zuvor gab es nur die Möglichkeit, mit rudimentären Log Shipping die Write Ahead Logfiles (WAL) remote auf einen anderen Server zu übertragen und dort einzulesen. Im Prinzip war diese Funktionalität nur eine Erweiterung des Archivierungsprozesses des Backup- und Recovery-Konzepts, bei dem die WAL-Dateien nicht einfach nur archiviert, sondern auch an entfernter Stelle kopiert wurden. Dies lief entsprechend stark asynchron ab und war auch alles andere als optimal in Bezug zur Netzwerkauslastung, da es sich im Hintergrund um dateibasierte Kopiervorgänge gehandelt hat.
Streaming Replication bietet eine effizientere Möglichkeit, die Daten zu einer Stand-by-Datenbank zu replizieren (s. Abb. 1).
Mit der Version 9.1 war dies dann auch vollständig synchron möglich, um so ein Failover ohne Datenverlust zu ermöglichen. Der lesende Zugriff auf der Stand-by-Datenbank ist dabei sowohl beim reinen Log Shipping als auch beim Einsatz von Streaming Replication möglich. Das Prinzip der Protection Modes von Oracle Data Guard lässt sich auch mit Parametern vergleichbar umsetzen.
Sowohl Log Shipping als auch Streaming Replication entsprechen technisch einer physikalischen Replikation. Dies bedeutet, dass die Daten blockbasiert verarbeitet werden.
Eine logische Replikation, wie es bei Data Guard mit dem SQL Apply gibt, wurde bei PostgreSQL erst viel später implementiert. Nach einigen frühen, auf SQL Trigger basierenden Lösungen von Drittherstellern wurde von 2ndQuadrant eine Erweiterung pglogical etabliert [2]. Die wesentliche Funktionalität dieser Erweiterung wurde dann – wie bei der Entwicklung von PostgreSQL häufig der Fall – in die Hauptentwicklung mit aufgenommen. Die Extension hat aber nach wie vor aufgrund einiger umfangreicherer Features ihre Daseinsberechtigung erhalten.
Die Replikation wird hierbei nicht mehr block- sondern transaktionell zeilenbasierend ausgeführt. Es werden zwar keine SQL Statements generiert, aber die resultierende Ausführung läuft auf das gleiche Ergebnis hinaus, und das auch völlig plattform- und versionsunabhängig. Wichtig ist, dass hier lediglich Datenmanipulationen repliziert werden. Sämtliche strukturelle Änderungen z. B. an Tabellendefinitionen müssen manuell auf beiden Seiten angepasst werden.
Logische Replikation bietet die Möglichkeit, nicht die komplette Datenbank, sondern nur bestimmte Objekte selektiv zu replizieren. Außerdem kann hierbei sowohl die primäre als auch die Stand-by-Datenbank lesend und schreibend öffnen. Wenn die dadurch mögliche Fragilität in Betracht gezogen und bei der Implementierung des Datenzugriffs berücksichtigt wird, bietet diese Flexibilität Raum für viele interessante Szenarien. Es zeigt aber auch, dass im Sinne von hochverfügbaren Systemen die logische Replikation in dieser Form nur eine Ergänzung ist und die physikalische Replikation nicht ablöst. Eine Kombination beider Technologien ist problemlos möglich. Bei Major Upgrades bietet logische Replikation eine Option, dies ohne lange Downtime zu realisieren.
Client Handling
Was die reine Replikation angeht, sind Oracle und PostgreSQL vergleichbar gut aufgestellt. Beim Thema Client Handling wird der bereits oben genannte philosophische Unterschied erneut deutlich. Wo Oracle beim Thema Connection Pooling und Client Failover diverse Technologien und Lösungen fest integriert, muss bei PostgreSQL je nach Anforderung auf Erweiterungen oder Lösungen von Drittherstellern zurückgegriffen werden. Die Standardverbindung über die Client Library libpq bietet nur rudimentär die Angabe von mehreren Zielhosts, die bis zum erfolgreichen Connect durchprobiert werden. Für umfangreichere Methoden bieten zum Beispiel etablierte Tools, wie PgPool, PgBouncer und HAProxy erweiterte Funktionalität. Für den Systemarchitekten ist es aber zurecht eine Herausforderung, die Entscheidung und das Vertrauen für eine oder mehrere externe Lösungen bzw. Erweiterungen aufzubringen.
Auch ein Failover bzw. Switchover lässt sich out-of-the-box bei Oracle durch die Broker-Kommandozeile deutlich direkter und intuitiver bedienen und bringt direkt automatische Reinstanzierung der neuen passiven Seite mit.
Ohne zusätzliche Software bietet PostgreSQL lediglich die Möglichkeit, den passiven Knoten zu promoten und damit aktiv zu schalten. Der ehemalige aktive Knoten muss dann nach der Fehlerkorrektur manuell angepasst und in den Replikationsverbund wieder eingebunden werden, was deutlich umständlicher als bei Data Guard ist. Es gibt z. B. mit dem REPMGR von 2ndQuadrant, dem Cluster Control von ServeralNines oder dem EnterpriseDB Failover Manager [2], sowohl kommerziell als auch Open Source hilfreiche und etablierte Lösungen für PostgreSQL.
Dies schreckt viele Administratoren und Architekten zweifellos ab, kann aber auch als Chance zur Unabhängigkeit gesehen werden. Hier kann die Lösung der Wahl evaluiert und angepasst werden, während bei Oracle der vorgegebene Weg feststeht – egal ob er gut oder schlecht in die eigenen Anforderungen passt.
Cluster-Management mit Patroni
Um bei PostgreSQL zumindest etwas Abhilfe und eine stabile und vor allem nicht unnötig komplexe Gesamtlösung zu schaffen, entwickelte der Versandhandel Zalando vor wenigen Jahren eine umfangreiche Lösung für ein Cluster-Management bei PostgreSQL. Mit der Lösung Patroni wird basierend auf Streaming Replication ein Cluster-Verbund von beliebig vielen Knoten verwaltet. Es existiert immer ein Master-Knoten, der in einen Konsensalgorithmus von allen Knoten gewählt wird und als einzig beschreibbarer Knoten erreichbar ist. Alle anderen Slave-Knoten werden über reguläres Streaming Replication repliziert und sind für Leseoperationen verfügbar. In einem Fehlerfall wird der Konsensalgorithmus einen entsprechenden neuen Knoten zum Master ernennen und etwaige defekte Knoten werden bei der Rückkehr automatisch reinstanziert und wieder in den Verbund aufgenommen. Die Logik des Algorithmus wird hierbei lediglich in einen kompakten Key/Value-Store verwaltet. Unter den reinen Open-Source-Lösungen ist Patroni aktuell die vielversprechendste und kompletteste Lösung eines automatisierten Mehrknoten-Clusters (s. Abb. 2).
Backup und Recovery
Entweder als Selbstverständlichkeit oder nicht als Teil einer Hochverfügbarkeitsstrategie angesehen ist das Thema Backup und Recovery etwas, was niemals außer Acht gelassen werden darf. Nicht zuletzt ist es auch bei der MAA von Oracle stetig als Rückgrat aller Lösungen vorhanden.
In der Basis stellen sowohl Oracle als auch PostgreSQL mit der Archivierbarkeit der Transaktionslogfiles die gleiche Grundlage bereit. Nur damit ist in Verbindung mit Online-Backups ein konsistentes Recovery der Datenbank entweder zu einer bestimmten Zeit oder zu der letzten erfolgreichen Transaktion möglich. Offline-Backups und logische Exports sind genauso bei beiden Systemen obligatorisch. Für traditionelle Backups sind beide Seiten damit zufriedenstellend aufgestellt. Jedoch bietet Oracle mit dem Recovery Manager (RMAN) out-of-the-box ein umfangreicheres Funktionsangebot mit eigener Benutzerschnittstelle, die bei PostgreSQL wiederum zum Teil nachgerüstet werden müsste.
Zweifellos wird nicht jedes Feature vermisst, aber insbesondere inkrementelle Backups wären als Kern-Feature wünschenswert gewesen. Es gibt wie gewohnt Lösungsansätze von etablierten Herstellern, die sowohl den Open-Source- als auch den kommerziellen Enterprise-Markt zufriedenstellend bedienen können. Die beiden bekanntesten sind BARMAN von 2ndQuadrant (Open Source) und BART von EnterpriseDB (kommerziell). Mit pgBackRest und pg_probackup gibt es noch zwei weitere freie und sinnvolle Erweiterungen, die bei der Evaluierung der Lösung berücksichtigt werden sollten.
Multi-Master-Replikation
Mit der höchsten Ausbaustufe für hochverfügbare Systeme hat Oracle beim Platinum-Standard der MAA zwischen den Rechenzentren eine bidirektionale Replikation eingeführt. Diese sogenannte Multi-Master-Replikation übernimmt bei Oracle die von der Datenbank unabhängige Lösungs-Suite Golden Gate.
Als Ablösung für das seit Kurzem nicht mehr unterstütztes Feature Oracle Streams wurde Golden Gate im Jahr 2009 eingekauft und für sämtliche Replikationslösungen auch von fremden Quell- oder Ziel-Datenbanken empfohlen. Technisch wird eine datei-basierte Zwischenspeicherung und Übertragung durchgeführt, woraufhin dann per logischem SQL Apply in die Ziel-Datenbank geschrieben wird. Grundsätzlich ist dies technisch bei PostgreSQL mit der logischen Replikation auch bidirektional möglich. Aber sämtliche Konfliktbehandlungen liegen in der Verantwortung des Users bzw. des Administrators.
Komplette Lösungen mit Berücksichtigung aller Seiteneffekte bieten nur kommerzielle Anbieter. EnterpriseDB hat hierfür den Replication Manager im Angebot, der – vergleichbar zu Oracle Golden Gate – auch andere Datenbanksysteme in eine Richtung unterstützt. Bei reinen PostgreSQL-Datenbanken ist auch eine bidirektionale Replikation möglich.
2ndQuadrant bringt mit der Lösung BDR ein Komplettpaket für hochverfügbare PosgreSQL-Cluster, welches sowohl physikalische also auch bidirektionale logische Replikation kombiniert. Im Gesamtkontext entspricht diese Lösung nahezu dem Konzept des Platinum-Standards der Oracle MAA.
Clustering
Hochverfügbarkeit mit dem Real Application Cluster (RAC) bedeutet, dass mehrere Server-Knoten mit laufenden Instanzen auf dem gleichen Datenbestand auf dem Storage zugreifen. Es lassen sich jederzeit weitere Knoten hinzufügen und auch entfernen und es spielt in der Theorie keine Rolle, über welchen Knoten oder auch parallelisiert über mehrere Knoten mit der Datenbank kommuniziert wird. Die Intelligenz dahinter liegt an der Kommunikation der Knoten untereinander, damit auch die Situation im Hauptspeicher berücksichtigt werden kann und da hat Oracle mit der Cache-Fusion-Technologie die Nase vorn. Die dadurch mögliche horizontale Skalierbarkeit ist etwas, was es in PostgreSQL und auch bei vielen anderen Datenbanksystemen nicht gibt und auch in naher Zukunft nicht geben wird. Fairerweise sei jedoch gesagt, dass die entsprechende Applikation auch bis ins Detail mitspielen muss, um das volle Potential optimal auszunutzen. In der Praxis ist es häufiger der Fall, dass Applikationen auf einen expliziten Knoten fixiert werden. Entweder manuell als Switchover oder im Fehlerfall als Failover kann auch dann der Knoten gewechselt werden. Dies ist technisch legitim, wird aber der Komplexität und dem Funktionsumfang eines RACs sicher nicht gerecht.
Wenn man Oracle und PostgreSQL beim Thema Hochverfügbarkeit vergleichen möchte, liegt der Fokus ausschließlich bei den beschriebenen replikationsbasierten Lösungen.
Lösungsgegenüberstellung Oracle und PostgreSQL
| Lösung | Oracle | PostgreSQL |
|---|---|---|
| Backup & Recovery | Data Pump, Recovery Manager (RMAN) | Dumps, pg_[base]backup, Erweiterungen (Barman, pg_probackup, pgBackRest) |
| Clustering | Real Application Cluster (RAC) | N/A (ggf. Failover Clustering) |
| Replikation | (Active) Data Guard | Streaming Replication, Logical Replication |
| MultiMaster-Replikation | Golden Gate (Zusatzsoftware) | 2ndQuadrant BDR, EDB Replication Manager (kommerzielle Lösungen) |
Zusammenfassung und Fazit
Es wäre naiv zu behaupten, dass PostgreSQL in allen Disziplinen für hochverfügbare Systeme mit den etablierten Funktionalitäten von Oracle auf Augenhöhe ist. Technologien – wie hier der Real Application Cluster – sind faktisch nicht existent und auch nicht in Aussicht. Für alle anderen Lösungen gibt es jedoch durchaus vergleichbare Lösungen, wenn auch mit Einschränkungen, die aber nicht immer eine Rolle spielen müssen.
Häufig ist die technische Basis identisch, aber das Gerüst bzgl. Bedienung und unterstützenden zusätzlichen Features fehlt in der Regel oder ist ausbaufähig und muss nachgerüstet werden.
Die Abhängigkeit von solchen Zusatzlösungen oder Erweiterungen schreckt viele Umsteiger anfangs ab. Die Angst vor einem unüberschaubaren Zoo aus Anbietern oder von nicht mehr weiterentwickelten bzw. unterstützten Lösungen ist zurecht groß. Man sollte aber auch die Chance dahinter nicht ignorieren, dass es dadurch auch viel Dynamik und Flexibilität bei der Wahl der Tools und Ansätze gibt und auch deutlich agiler auf Veränderungen reagiert werden kann. Die damit gewonnene Freiheit und Unabhängigkeit entspricht auch dem Spirit von Open-Source-Lösungen.
Die vergangenen 10 Jahre haben deutlich gezeigt, wie sehr die Entwicklung von PosgreSQL in Richtung einer Enterprise-Tauglichkeit gegangen ist. Es haben sich auch unter den Tools und Erweiterungen viele langjährig etablierte Lösungen herauskristallisiert, die ein gewisses Maß an Vertrauen verdient haben. In der Regel stecken hinter der Entwicklung von solchen Erweiterungen etablierte Firmen, die sich auch an die Entwicklung vom Open-Source-Projekt PostgreSQL beteiligen. Wie bei der oben genannten Erweiterung pglogical von 2ndQuadrant fließen entsprechend Funktionalitäten auch nicht selten in die Hauptentwicklung mit ein. Der Community-Gedanke ist auch bei kommerziellen Anbietern stark verankert, was eine wesentliche Stärke von PostgreSQL ist.
Die Frage nach der Enterprise-Tauglichkeit von PostgreSQL gegenüber Oracle ist auf jeden Fall mit Ja zu beantworten. Dennoch sollte die Wahl der Technik wohlüberlegt und evaluiert werden, was aber bei sämtlichen Lösungen der Fall sein sollte.
weitere Informationen:
- PostgreSQL: Offizielle Dokumentation
S. M. Thomas; 2020: PostgreSQL 12 High Availability Cookbook (3rd Edition)
- Oracle: Offizielle Dokumentation
