In den letzten Monaten habe ich im Rahmen des AXLE-Projekts an Online-Upgrades für sehr große Datenbanken gearbeitet und möchte meine Gedanken zu diesem Thema und den Fortschritten, die wir in letzter Zeit erzielt haben, mitteilen.
Bevor ich zu 2ndQuadrant kam, arbeitete ich bei Skype, wo das Unternehmen kein Wartungsfenster für unsere Datenbanken zuließ. Dies bedeutete, dass keine Ausfallzeiten für Bereitstellungen, Upgrades usw. zulässig waren. Diese Art von Regel veranlasst Sie, die Art und Weise, wie Sie Dinge tun, zu ändern. Die meisten Änderungen sind klein, Sie führen keine schweren Sperren durch, Sie haben Replikate, um ein schnelles Failover zu ermöglichen. Aber während Sie Ihre Releases klein und nicht blockierend machen können, was passiert, wenn Sie ein Upgrade der Hauptversion der PostgreSQL-Datenbank durchführen müssen?
Möglicherweise befinden Sie sich in einer anderen Situation, da die meisten Unternehmen ein Upgrade-Fenster haben und Sie sich während des Upgrades möglicherweise eine gewisse Ausfallzeit leisten können. Dies bringt jedoch zwei Probleme mit sich. Zum einen mag eigentlich kein Unternehmen die Ausfallzeiten, auch wenn sie erlaubt sind. Und was noch wichtiger ist, wenn Ihre Datenbank über Gigabyte hinaus in den Bereich von Terabyte oder Hunderten von Terabyte anwächst, kann die Ausfallzeit Tage oder sogar Wochen dauern, und niemand kann es sich leisten, den Betrieb so lange zu unterbrechen. Das Ergebnis ist, dass viele Unternehmen oft wichtige Upgrades überspringen, was das nächste noch schmerzhafter macht. Und den Entwicklern fehlen neue Funktionen, Leistungsverbesserungen. Sie (die Unternehmen) riskieren manchmal sogar, eine PostgreSQL-Version zu verwenden, die nicht mehr unterstützt wird und bekannte Datenbeschädigungen oder Sicherheitsprobleme aufweist. In den folgenden Abschnitten werde ich ein wenig über meine Arbeit sprechen, um die Upgrades weniger zeitaufwändig und als Ergebnis weniger schmerzhaft und hoffentlich häufiger zu machen.
Lassen Sie mich zunächst mit einer kleinen Geschichte beginnen. Vor PostgreSQL 9.0 bestand die einzige Möglichkeit, ein Hauptversions-Upgrade durchzuführen, darin, pg_dump auszuführen und den Dump in einer Instanz wiederherzustellen, auf der eine neuere Version von PostgreSQL ausgeführt wird. Bei dieser Methode mussten die Struktur und alle Daten aus der Datenbank gelesen und in eine Datei geschrieben werden. Dann aus der Datei gelesen und in eine neue Datenbank eingefügt, Indizes müssen neu aufgebaut werden usw.
Wie Sie sich vorstellen können, kann dieser Vorgang einige Zeit in Anspruch nehmen. In 8.4 wurde die Leistung für pg_restore verbessert, indem die Option -j hinzugefügt wurde, mit der Sie angeben konnten, wie viele parallele Jobs ausgeführt werden sollen. Dadurch können mehrere Tabellen (Indizes usw.) parallel wiederhergestellt werden, wodurch der Wiederherstellungsprozess für benutzerdefinierte Format-Dumps beschleunigt wird. Die Version 9.3 fügte pg_dump eine ähnliche Option hinzu, wodurch die Leistung noch weiter verbessert wurde. Angesichts der schnell wachsenden Datenmengen reicht die Parallelisierung jedoch nicht aus, um die erforderliche Zeit für das Upgrade ernsthaft zu verlängern.
Dann kam in PostgreSQL 9.0 ein Dienstprogramm namens pg_upgrade. Pg_upgrade sichert nur die Strukturen und stellt sie im neuen Cluster wieder her. Aber es kopiert die Datendateien so, wie sie sich auf der Festplatte befinden, was viel schneller ist, als sie in ein logisches Format zu kopieren und dann wieder einzufügen. Dies ist gut genug für kleine Datenbanken, da es eine Ausfallzeit im Bereich von Minuten oder Stunden bedeutet, eine Zeit, die für viele Szenarien akzeptabel ist. Es gibt auch den Link-Modus, der nur harte Links (Verbindungspunkte unter Windows) erstellt, was diesen Prozess noch schneller macht. Aber aus meiner persönlichen Sicht ist es zu gefährlich, ein solches Setup auf einem Produktions-Master-Server auszuführen. Warum, erkläre ich kurz. Wenn etwas schief geht, haben Sie nach dem Start Ihres neuen Servers, der im Verbindungsmodus aktualisiert wurde, plötzlich keine Produktionsdatenbank und müssen ein Failover durchführen, oder schlimmer noch, Sie müssen aus einer Sicherung wiederherstellen. Das bedeutet, dass Sie nicht nur beim Upgrade gescheitert sind, sondern auch zusätzliche Ausfallzeiten verursacht haben! Viel Glück beim nächsten Mal.
Jetzt verwenden viele Leute, die sich keine langen Ausfallzeiten für Upgrades leisten können, die Trigger-basierten Replikationslösungen wie Slony oder Londiste, um das Upgrade durchzuführen. Dies ist eine gute Lösung, da Sie Ihre Daten replizieren können, während der ursprüngliche Server läuft, und dann mit minimaler Ausfallzeit wechseln können. In der Praxis gibt es jedoch mehrere Probleme. Eine davon ist, dass die Trigger-basierten Lösungen oft umständlich einzurichten sind, insbesondere wenn Sie dies nur alle paar Jahre tun und nur, um das Upgrade durchzuführen. Es ist auch leicht, eine Tabelle zu übersehen oder Tabellen in der falschen Reihenfolge hinzuzufügen und so nicht die vollständige Kopie zu erhalten. Ich habe dies in der Praxis beobachtet und Leute, die das Upgrade durchführten, arbeiteten täglich mit der Trigger-basierten Replikation . Ein weiteres Problem besteht darin, dass die Trigger-basierten Lösungen die Quelldatenbank erheblich belasten, wodurch das Upgrade manchmal unmöglich wird, da der Datenbankserver nach Aktivierung der Replikation überlastet wird. Und nicht zuletzt kann es sehr lange dauern, bis die triggerbasierte Replikation die Daten tatsächlich auf den neuen Server verschiebt. Als ich das letzte Mal an einem Upgrade-Projekt beteiligt war, brauchte die Trigger-basierte Lösung etwa einen Monat, um die Datenbank zu kopieren und Änderungen nachzuholen. Ja, einen Monat.
Mit PostgreSQL 9.4 kommt die logische Dekodierungsfunktion, die einen Neuanfang für die Entwicklung einer neuen und besseren Online-Upgrade-Problemlösung bietet. Als Teil des AXLE-Projekts haben wir ein Tool entwickelt, das die logische Dekodierung mit den oben beschriebenen Techniken kombiniert. Die Lösung löst die meisten Probleme bisheriger Ansätze. Die Uni-Directional Replication PostgreSQL-Erweiterung (kurz UDR) führt eine logische Replikation durch, indem sie die logische Dekodierung des Write-Ahead-Logs (WAL) verwendet. Dadurch ist die Belastung des Master-Servers fast gleichauf mit der physischen Streaming-Replikation, sodass die zusätzliche Belastung durch laufende Upgrades auf dem laufenden System minimal ist. Außerdem bietet es Tools zum Initialisieren neuer Knoten, sowohl mit physischer als auch mit logischer Sicherung. Sie können sogar einen vorhandenen physischen Standby-Modus in UDR-Standby umwandeln. Und da es sich um ein logisches Replikationssystem handelt, ist es möglich, es so zu gestalten, dass die Replikation über mehrere Versionen hinweg unterstützt wird.
All dies bedeutet, dass wir jetzt UDR in Kombination mit pg_upgrade verwenden können, um ein Online-Upgrade der Hauptversion von PostgreSQL mit minimaler Ausfallzeit, in kurzer absoluter Zeit und mit minimaler Auswirkung auf das laufende System durchzuführen.
Ein Beispiel, wie das in der Praxis aussehen kann:
- Führen Sie pg_basebackup der vorhandenen Instanz durch.
- Richten Sie die UDR-Replikation zwischen der ursprünglichen Instanz und der von basebackup erstellten ein.
- Pg_upgrade die neue Instanz.
- Lassen Sie UDR die zwischenzeitlich erfolgten Änderungen wiedergeben.
- Schalten Sie den Datenverkehr auf die neue Instanz um.
Eine Anleitung mit detaillierteren Anweisungen finden Sie im UDR-Online-Upgrade-Leitfaden im PostgreSQL-Wiki. Die UDR-Quellen sind im 2ndquadrant_bdr-Repository auf dem PostgreSQL-Git-Server (bdr-plugin/next branch) verfügbar.
Da UDR schließlich nicht nur ein Online-Upgrade-Tool, sondern auch eine Replikationslösung ist, kann es anstelle der physischen Streaming-Replikation für Ihre normalen Replikationsanforderungen verwendet werden. Darüber hinaus bietet es mehrere Vorteile wie die Möglichkeit, temporäre Tabellen zu erstellen, aus mehreren OLTP-Datenbanken in eine Big-Data-Warehouse-Datenbank zu replizieren oder nur einen Teil der Datenbank zu replizieren.
Ich hoffe, dass diese Bemühungen dazu führen, dass Überlegungen zu Ausfallzeiten kein Problem mehr darstellen, wenn es darum geht, von PostgreSQL 9.4 und höher auf eine neue Hauptversion zu aktualisieren.
Die zu diesen Ergebnissen führende Forschung wurde vom Siebten Rahmenprogramm der Europäischen Union (RP7/2007-2013) unter der Finanzhilfevereinbarung Nr. 318633 finanziert.
