PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Das PostgreSQL-Upgrade entwirren

PostgreSQL 9.6 wurde gerade veröffentlicht und die meisten Postgres-Benutzer werden sich fragen, wie sie auf die neue Hauptversion aktualisieren können. Dieser Beitrag hat die Absicht, verschiedene Verfahren zum Aktualisieren Ihres PostgreSQL-Servers aufzuzeigen.

Das Upgrade auf eine neue Hauptversion ist eine Aufgabe, die einen hohen Anteil an Vorbereitung gegenüber der gesamten Ausführungszeit hat. Insbesondere beim Überspringen einer Version in der Mitte, z. B. wenn Sie von Version 9.3 auf Version 9.5 wechseln.

Punktfreigaben

Auf der anderen Seite benötigen Point-Release-Upgrades nicht so viel Vorbereitung. Im Allgemeinen besteht die einzige Anforderung darin, dass der Postgres-Dienst neu gestartet wird. Es gibt keine Änderungen an der zugrunde liegenden Datenstruktur, sodass kein Dump und keine Wiederherstellung erforderlich ist. Im schlimmsten Fall müssen Sie möglicherweise einige Ihrer Indizes neu erstellen, nachdem Sie das Upgrade der Punktversion abgeschlossen haben.

Es ist sehr ratsam, immer auf dem neuesten Point-Release zu bleiben, damit Sie nicht über einen bekannten (und wahrscheinlich behobenen) Fehler stolpern. Das bedeutet, sobald die neueste Version verfügbar ist, sollten Sie so schnell wie möglich einen Zeitpunkt für das Upgrade einplanen.

Hauptversions-Upgrade

Bei komplexen Aufgaben wie dieser ist es gut, alle möglichen Optionen in Betracht zu ziehen, um das Endergebnis zu erzielen.

Für Upgrades auf Hauptversionen gibt es drei mögliche Wege, die Sie einschlagen können:

  • Upgrade-Wiederherstellung aus einem logischen Dump
  • Physisches Upgrade
  • Online-Upgrade

Lassen Sie mich jeden im Detail erklären:

1) Upgrade-Wiederherstellung aus einem logischen Dump

Dies ist die einfachste aller Möglichkeiten, die Datenstruktur Ihres Clusters zu aktualisieren.

Um es kurz zu machen, der Prozess hier erfordert einen logischen Dump mit pg_dump von der alten Version und pg_restore auf einem sauberen Cluster, der mit der neu installierten Version erstellt wurde.

Wichtige Punkte, die für die Verwendung dieses Pfads sprechen, sind:

  • Es ist das am meisten getestete
  • Die Kompatibilität geht zurück auf die 7.0-Versionen, sodass Sie eventuell von 7.x auf eine der neueren Versionen upgraden können

Gründe, warum Sie diese Option vermeiden sollten:

  • Die Gesamtausfallzeit bei großen Datenbanken kann ein Problem sein, da Sie Schreibverbindungen stoppen müssen, bevor Sie pg_dump ausführen;
  • Wenn es viele große Objekte in der Datenbank gibt, wird pg_dump langsam sein. Auch wenn man es parallel macht. Die Wiederherstellung ist sogar noch langsamer als pg_dump, wenn viele große Objekte in der Datenbank gespeichert sind;
  • Es erfordert doppelten Speicherplatz oder das Entfernen des alten Clusters vor der Wiederherstellung;

Auf Servern mit mehreren CPU-Kernen ist es möglich, pg_dump parallel über das Verzeichnisformat auszuführen. Sobald es fertig ist, stellen Sie auch parallel wieder her, indem Sie den Schalter -j sowohl in pg_dump als auch in pg_restore verwenden. Sie können den Wiederherstellungsprozess jedoch erst starten, wenn der gesamte Dump abgeschlossen ist.

2) Physisches Upgrade

Diese Art von Upgrades sind seit Version 9.0 verfügbar, um In-Place-Upgrades von Versionen so alt wie 8.3 durchzuführen. Sie werden „in-place“ genannt, weil sie über denselben Server und vorzugsweise im selben Datenverzeichnis ausgeführt werden.

Vorteile dieser Art von Upgrades:

  • Sie benötigen keinen Platz für eine weitere Kopie des Clusters.
  • Die Ausfallzeit ist viel geringer als bei der Verwendung von pg_dump.

Es gibt einige Nachteile:

  • Sobald Sie die neue Version von PostgreSQL gestartet haben, gibt es kein Zurück mehr zur alten Version (Cluster funktioniert von da an nur noch mit der neuen Version).
  • Statistiken werden nach dem Upgrade genullt, daher muss direkt nach dem Start der neuen Version von PostgreSQL eine clusterweite Analyse durchgeführt werden.
  • In den letzten Jahren wurden viele Fehler in Bezug auf pg_upgrade gefunden, was einige Datenbankadministratoren davon abhält, diese Methode für das Upgrade zu verwenden.
  • Einige Leute hatten Probleme beim Überspringen einer Hauptversion, beispielsweise beim Wechsel von Version 9.2 zu Version 9.4.
  • Bei großen Katalogen wird es schlecht funktionieren (Cluster mit vielen Datenbanken oder Datenbanken mit vielen tausend Objekten).

Sie können pg_upgrade auch ohne die Option –link ausführen (in diesem Fall erstellt pg_upgrade eine zweite Kopie auf der Festplatte Ihres Clusters), sodass Sie zur alten Version zurückkehren können. Sie verlieren jedoch beide oben aufgeführten Vorteile.

3) Online-Upgrade

Das für diese Methode zu befolgende Verfahren wäre wie folgt:

  1. Installieren Sie beide Versionen, damit Sie parallel arbeiten können. Dies kann auf demselben Server oder mit zwei physischen Servern erfolgen.
  2. Erstellen Sie eine anfängliche Kopie und replizieren Sie die Änderungen ab dem Zeitpunkt, an dem Sie die Kopie auf dem Quellknoten gestartet haben (dies wäre ähnlich wie bei einem anfänglichen pg_dump).
  3. Replizieren Sie die Änderungen logisch weiter, bis die Verzögerung nahe Null ist.
  4. Repoint the connection info from the application server to connect to the new server.

Diese Art von Upgrade ist verfügbar, seit es die ersten Trigger-basierten Replikationslösungen gab. Mit anderen Worten, seit Slony-I da war.

Triggerbasierte Replikationslösungen kümmern sich nicht darum, welche Version Sie auf der einen oder anderen Seite haben, da sie die Änderungen mit unterstützten SQL-Befehlen kopieren.

Die empfohlenen Trigger-basierten Replikationstools sind in der angegebenen Reihenfolge:

  1. skytools:PgQ + londiste
  2. Slony-I

Dies sollte die bevorzugte Methode für das Upgrade sein. Sehen wir uns die Vorteile dieser Methode an:

  • Keine Ausfallzeit!
  • Großartig auch für Upgrades auf neuere Hardware.
  • Online-Test des Clusters mit der neuen Version (Nur-Lese-Abfragen, sonst könnten Konflikte auftreten).
  • Reduziert drastisch alle Tabellen- und Indexaufblähungen.

Es gibt einige Nachteile:

  • Es benötigt doppelten Speicherplatz, da es eine zweite Kopie Ihrer Daten speichern muss.
  • Da es auf Triggern basiert, muss das System jede Änderung zweimal schreiben, was bedeutet, dass auf dem Quellserver (alte Version des Clusters) mehr Festplatten-E/A anfällt.
  • Alle Tabellen müssen einen Primärschlüssel haben, damit das Replikationstool die aktualisierten oder gelöschten Tupel individualisieren kann
  • Katalogtabellen werden nicht repliziert, daher werden keine großen Objekte repliziert.
  • Die grundlegende Verwendung deckt keine Schemaänderungen ab. Es ist möglich, aber nicht transparent.

Eine neue Grenze mit pglogical

Seit PostgreSQL 9.4 haben wir eine logische Dekodierung der Transaktionsprotokolle. Das bedeutet, dass wir jetzt die Transaktionen von der WAL entschlüsseln und die Ausgabe manipulieren können.

Auf dem Gebiet der Replikation tauchte eine ganz neue Welt voller Möglichkeiten auf. Trigger sind nicht mehr erforderlich, um eine logische Replikation zu erreichen!

Das bedeutet im Grunde, dass Sie keine separate Kopie aller Einfügungen, Aktualisierungen und Löschungen mehr speichern müssen, die Trigger verwenden. Sie können diese Datenmanipulationsvorgänge einfach aus den Transaktionsprotokollen abrufen, indem Sie sie entschlüsseln. Dann muss das von Ihnen verwendete Tool die Ausgabe manipulieren und an den abonnierten Downstream-Knoten senden. In diesem Fall ist dieses Tool pglogical.

Also, was bedeutet das alles?

Nun, wenn Sie eine Version 9.4 oder 9.5 von PostgreSQL verwenden und auf 9.6 aktualisieren möchten, können Sie ein Online-Upgrade wie das oben beschriebene durchführen, aber mit pglogical anstelle einer der Trigger-basierten Replikationslösungen.

Ich werde nicht weiter ins Detail gehen, da es andere Blogs zu diesem speziellen Thema gibt, wie diesen von Petr Jelinek:PPGLogical 1.1-Pakete für PostgreSQL 9.6beta1

Schlussfolgerungen

Abhängig vom Schema Ihrer Datenbank, der Datengröße, dem möglichen Ausfallzeitfenster und der Version der aktuellen PostgreSQL-Installation können Sie eine Option einer anderen vorziehen oder was auch immer am besten passt.

  • Wenn Ihre Datenbank klein ist und es ein geeignetes Wartungsfenster gibt, das Sie verwenden können, können Sie sich für die Ausführung von pg_dump und pg_restore entscheiden. Abhängig von der Größe des Datensatzes gibt es einen Punkt, an dem die Option nicht mehr praktikabel ist.
  • Wenn Sie über eine große Datenbank verfügen (mehrere hundert GB oder sogar TB an Daten), müssen Sie nach anderen Optionen wie einem direkten Upgrade mit pg_upgrade oder einem Online-Upgrade suchen.
    • Wenn Sie von Version 8.3 oder höher auf eine Version 9.x upgraden, können Sie pg_upgrade verwenden.
    • Bei älteren Versionen als 8.3 müssen Sie sich für eine der logischen Replikationslösungen wie londiste oder slony entscheiden.
    • Bei einer 9.4- oder 9.5-Datenbank ist pglogical besser dran.

Denken Sie immer daran, dass die Tabellen für die logische Replikation einen Primärschlüssel haben müssen.

Mit pglogical ist diese Regel nicht so streng:Sie können Nur-Einfüge-Tabellen replizieren. Aber für Aktualisierungen und Löschungen ist es immer noch obligatorisch, einen Primärschlüssel oder eine REPLICA IDENTITY in der Tabelle zu haben.

Wenn Sie Hilfe beim Upgrade Ihrer PostgreSQL-Datenbank benötigen, können Sie sich die
2ndQuadrant Upgrade-Dienste ansehen.