Letzte Woche war ich auf dem Nordic PGDay 2018 und hatte einige Gespräche über das Tool, das ich geschrieben habe, nämlich pglupgrade , um PostgreSQL-Hauptversions-Upgrades in einem Replikations-Cluster-Setup zu automatisieren. Ich war ziemlich froh, dass es gehört wurde und einige andere Leute in verschiedenen Communities Vorträge auf Meetups und anderen Konferenzen über Upgrades mit nahezu null Ausfallzeit durch logische Replikation hielten. Da es einen Vortrag gibt, den ich beim PGDAY'17 Russia, PGConf.EU 2017 in Warschau und zuletzt beim FOSDEM PGDay 2018 in Brüssel gehalten habe, hielt ich es für besser, einen Blogbeitrag zu erstellen, um diese Präsentation für die Leute zugänglich zu machen, die es könnten nicht zu einer der oben genannten Konferenzen kommen. Wenn Sie direkt zum Vortrag übergehen und das Lesen dieses Blogbeitrags überspringen möchten, finden Sie hier Ihren Link:Near-Zero Downtime Automated Upgrades of PostgreSQL Clusters in Cloud
Die Hauptmotivation hinter der Entwicklung dieses Tools bestand darin, eine Lösung vorzuschlagen, um die Ausfallzeiten während größerer Versions-Upgrades zu minimieren, die leider fast jeden betreffen, der PostgreSQL verwendet. Derzeit haben wir kein Tool, mit dem PostgreSQL-Benutzer ihre Datenbanken ohne Ausfallzeiten aktualisieren können, und dies ist eindeutig ein Schmerzpunkt für viele Benutzer, insbesondere für Unternehmen. Und wenn wir das Upgrade-Problem lösen wollen, sollten wir an mehr als einen Server denken (im Folgenden als Cluster bezeichnet), einfach weil nicht mehr viele Leute nur einen Datenbankserver verwenden. Das häufigste Szenario ist die Einrichtung einer physischen Streaming-Replikation, entweder für Hochverfügbarkeitszwecke oder zum Skalieren der Leseabfragen.
Datenbank-Upgrades
Bevor wir uns mit der Lösung befassen, lassen Sie uns ein wenig darüber diskutieren, wie Datenbank-Upgrades im Allgemeinen funktionieren. Es gibt vier mögliche Ansätze für Datenbank-Upgrades:
- Der erste Ansatz wäre, dass Datenbanken ihr Speicherformat über Versionen hinweg gleich oder zumindest kompatibel halten. Dies ist jedoch langfristig schwer zu garantieren, da neue Funktionen möglicherweise Änderungen in der Art und Weise erfordern, wie Daten gespeichert werden, oder mehr Metadateninformationen hinzufügen, um ordnungsgemäß zu funktionieren. Außerdem wird die Leistung oft durch Optimierung der Datenstrukturen verbessert.
- Der zweite Ansatz besteht darin, eine logische Kopie (Dump) des alten Servers zu erstellen und sie auf den neuen Server zu laden. Dies ist der traditionellste Ansatz, der erfordert, dass der alte Server während des Vorgangs keine Updates erhält, und führt zu verlängerten Ausfallzeiten von Stunden oder sogar Tagen bei großen Datenbanken.
- Die dritte Option besteht darin, Daten vom alten Format in das neue zu konvertieren. Dies kann entweder on-the-fly erfolgen, während das neue System läuft, führt jedoch zu Leistungseinbußen, die schwer vorherzusagen sind, da dies von den Datenzugriffsmustern abhängt, oder es kann offline erfolgen, während die Server ausgefallen sind, was wiederum lang andauert Ausfallzeiten (obwohl oft kürzer als die zweite Methode).
- Die vierte Methode besteht darin, den logischen Dump zum Speichern und Wiederherstellen der Datenbank zu verwenden, während die zwischenzeitlichen Änderungen erfasst werden und logisches Replizieren in die neue Datenbank, sobald die anfängliche Wiederherstellung abgeschlossen ist. Diese Methode erfordert die Orchestrierung mehrerer Komponenten, verringert aber auch die Zeitspanne, in der die Datenbank nicht auf Abfragen reagieren kann.
Upgrade-Methoden in PostgreSQL
PostgreSQL-Upgrades können mit den vier oben aufgeführten Methoden abgeglichen werden. Beispielsweise ändern PostgreSQL-Minor-Releases, die keine neuen Features, sondern nur Fixes enthalten, das bestehende Datenformat nicht und passen zum ersten Ansatz. Für den zweiten Ansatz stellt PostgreSQL Tools namens pg_dump und pg_restore bereit, die die logische Sicherung und Wiederherstellung durchführen. Es gibt auch das pg_upgrade-Tool (es war ein Contrib-Modul und wurde in PostgreSQL 9.5 in den Hauptbaum verschoben), das offline (die Server laufen nicht) die Konvertierung des alten Datenverzeichnisses in das neue durchführt, das in die dritte Option passen kann. Für den vierten Ansatz gibt es Trigger-basierte Lösungen von Drittanbietern wie Slony zum Upgraden, aber sie haben einige Einschränkungen, auf die wir später eingehen werden.
Herkömmliche Upgrade-Methoden können nur Aktualisieren Sie den primären Server, während die Replica-Server anschließend neu erstellt werden müssen (Offline-Konvertierung) . Dies führt zu zusätzlichen Problemen sowohl mit der Cluster-Verfügbarkeit als auch mit der Kapazität, wodurch die wahrgenommene Ausfallzeit effektiv erhöht wird der Datenbank sowohl aus Sicht der Anwendungen als auch der Benutzer. Die logische Replikation ermöglicht die Replikation während das System in Betrieb ist und Testaufwand kann zwischenzeitlich (Online-Konvertierung) bewältigt werden .
Es gibt verschiedene Upgrade-Methoden, die für verschiedene Umgebungen anwendbar sind. Zum Beispiel pg_dump ermöglicht ein Upgrade von sehr alten Versionen (z. B. 7.0) zu neueren Versionen, wenn Sie also eine antike Version von PostgreSQL verwenden, ist die beste Methode die Verwendung von pg_dump/restore (und besser gleich!). Wenn Ihre PostgreSQL Version 8.4 und höher ist Sie können pg_upgrade verwenden . Falls Sie PostgreSQL 9.4 und höher verwenden das bedeutet, dass Sie im Kern "logische Dekodierung" haben und Sie können das pglogical verwenden Verlängerung als Upgrade. Schließlich, wenn Sie PostgreSQL 10 verwenden haben Sie die Möglichkeit, Ihre Datenbank auf PostgreSQL 11 und höher zu aktualisieren (sobald sie verfügbar sind) mithilfe von „Logischer Replikation“ im Kern (Juhu!).
Logische Replikation für Upgrades
Wo ist die Idee, PostgreSQL mithilfe der logischen Replikation zu aktualisieren? aus?Eindeutig pglogisch beansprucht den Upgrade-Zweck nicht offen wie pg_upgrade tut (dies war ein Argument gegen pglogical auf der Konferenzparty ), Dies bedeutet jedoch nicht, dass wir das Tool nicht für Upgrades verwenden können. Als pglogical entworfen wurde, wurden Upgrades mit nahezu null Ausfallzeit von den Entwicklern der Erweiterung als einer der erwarteten Anwendungsfälle angesehen.
Im Gegensatz zur physischen Replikation, die Änderungen an den Rohdaten auf der Festplatte erfasst, erfasst die logische Replikation die logischen Änderungen an den einzelnen Datensätzen in der Datenbank und repliziert diese. Die logischen Datensätze funktionieren über Hauptversionen hinweg , daher kann die logische Replikation zum Upgrade verwendet werden von einer Ausgabe zur anderen. Die Idee, die logische Replikation als Mittel zur Versionsaktualisierung zu verwenden, ist alles andere als neu, Trigger-basierte Replikationstools haben Upgrades auf logische Weise durchgeführt, indem sie die Änderungen über Trigger erfasst und gesendet haben (weil Trigger auch unabhängig von Datenbankversionen funktionieren können! ).
Wenn Sie Trigger-basierte Replikationslösungen für Upgrades mit minimaler Ausfallzeit verwenden können, warum sollten Sie stattdessen die logische Replikation bevorzugen? Bei einem Trigger-basierten Mechanismus werden alle Änderungen mithilfe von Triggern erfasst und in Warteschlangentabellen geschrieben. Dieses Verfahren verdoppelt die Schreibvorgänge, verdoppelt Protokolldateien und verlangsamt das System, da alle Änderungen zweimal geschrieben werden müssen; was zu mehr Festplatten-E/A und Last auf dem Quellserver führt. Im Gegensatz dazu baut die logische Replikation im Kern (dasselbe gilt für die pglogical-Erweiterung) auf der logischen Dekodierung auf. Die logische Dekodierung ist ein Mechanismus, der Informationen aus WAL-Dateien in logische Änderungen extrahiert (INSERT/UPDATE/DELETE). Da die Daten vom WAL-Mechanismus zum Decodieren der Transaktionsprotokolle verwendet werden, gibt es keine Schreibverstärkung wie im Fall von Trigger-basierten Replikationslösungen, daher ist diese Methode leistungsstärker . Infolgedessen haben auf logischer Decodierung basierende Lösungen einfach eine geringere Auswirkung auf das System als triggerbasierte Lösungen.
Schlussfolgerung
In diesem Einführungsbeitrag wollte ich Ihnen eine Vorstellung davon vermitteln, warum wir die Verwendung der logischen Replikation in Betracht ziehen sollten, um bei größeren Versionsupgrades minimale Ausfallzeiten zu erreichen. Wir werden mit den Details der Architektur und Implementierung des Tools im nächsten Beitrag fortfahren.
