5 Antworten

Mach keinen einfachen pg_dump und restore in einer leeren Datenbank, wenn du nicht stundenlang Ausfallzeit haben willst - benutz stattdessen pg_upgrade, das auf dem gleichen Server läuft ohne Export/Import, oder wenn du zu einem anderen Server migrieren willst, nutz logische Replikation, um die App am Laufen zu halten während die Synchronisierung läuft. Mit 50GB sparst du dir eine Menge Zeit und Stress, wenn du es auf die Weise machst.

Kann deine Anwendung eine Weile ohne Schreibvorgänge in die Datenbank auskommen, oder brauchst du absolut null Ausfallzeit? Wenn du die Schreibvorgänge auch nur 5-10 Minuten unterbrechen kannst, ist pg_upgrade deine beste Freundin, weil sie die Dateien auf der gleichen Festplatte konvertiert, ohne etwas zu exportieren - mit 50GB sparst du dir also Stunden. Wenn du aber Ausfallzeit komplett vermeiden musst, gibt es einen Trick, den nur wenige erwähnen: Du kannst logische Replikation (logical replication) nutzen, um die alte Datenbank mit der neuen parallel zu synchronisieren, während sie weiterläuft, und dann switchest du, wenn alles aktuell ist - das ist etwas komplizierter einzurichten, aber es ist gold, wenn du den Service nicht stoppen kannst. Aber vorher testest du das auf jeden Fall in einer Staging-Umgebung, auch nur mit einem Dump von ein paar GB, um zu sehen, wie lange es bei deinem speziellen Setup dauert.

DiegoHernandez asker Wir können die Schreibvorgänge problemlos 10 Minuten lang stoppen. Ich werde dann pg_upgrade ausprobieren, danke für den Tipp.

Hast du bereits überprüft, ob deine Version 12 direkt mit 15 kompatibel ist, oder musst du über Zwischenversionen gehen? Was niemand erwähnt, ist, dass du neben pg_upgrade auch ein vollständiges Backup vor allem anderen machen solltest, denn obwohl pg_upgrade ziemlich zuverlässig ist, gibt dir dieses Backup ein beruhigendes Gefühl - besonders bei 50GB. Falls du auf jeden Fall Ausfallzeiten vermeiden musst, gibt es logische Replikation (logical replication), wo du eine sekundäre Instanz mit Version 15 konfigurierst, sie parallel synchronisierst und dann das Failover machst, wenn es bereit ist, aber das ist komplizierter. Die meisten Leute, die ich kenne, entscheiden sich am Ende für pg_upgrade mit einem kurzen Wartungsfenster, weil es für ein solches Datenvolumen am praktischsten und schnellsten ist.

Mit 50GB musst du vorsichtig sein, aber pg_upgrade ist tatsächlich die richtige Option, wenn du eine Ausfallzeit von 5 - 10 Minuten verkraften kannst. Was die meisten nicht erwähnen: PostgreSQL 12 zu 15 ist ein Sprung, den pg_upgrade ohne Probleme in einem einzigen Durchgang schafft, also brauchst du keine Zwischenversionen. Mein Rat: Mach vor allem anderen ein komplettes Backup mit pg_basebackup oder pg_dump parallel (nutze pg_dump mit der Option -j zum Parallelisieren, spart erheblich Zeit), und dann führe pg_upgrade auf deinem Produktionsserver während eines Wartungsfensters aus. Aber danach musst du ANALYZE auf den großen Tabellen ausführen, weil sich einige interne Statistiken ändern und du hättest sonst möglicherweise langsame Abfragen.

Schau, wenn du 10-15 Minuten Ausfallzeit verkraften kannst, ist pg_upgrade definitiv dein Weg, weil die Migration auf demselben Server stattfindet, ohne die ganzen Daten zu exportieren und zu importieren (mit 50GB sparst du dir damit eine Menge Zeit). Was hier niemand erwähnt hat, ist, dass du vorher auf jeden Fall checken musst, ob installierte Erweiterungen zwischen den Versionen kompatibel sind, weil das den ganzen Prozess im letzten Moment lahmlegen kann und dir unangenehme Überraschungen beschert, wenn du already bei der Konvertierung bist. Meine Empfehlung: Mach auf jeden Fall ein vollständiges Backup mit pg_basebackup (sicherheitshalber), test alles erst auf einem Staging-Server, und dann kannst du dich mit pg_upgrade in der Produktion reinwerfen.

Deine Antwort

Anmeldenzum Beantworten.