Hallo Luca,

meine Notizen zu einem solchen Upgrade: ############################################################## Postgres-Upgrade (11->13)

# vorhanden war v11 aus Debian 10 # nach dem Distupgrade war v13 als 2. Instanz auf Port 5433 gestartet

pg_dropcluster --stop 13 main

pg_upgradecluster 11 main # wenn nicht anders angegeben wird von der alten Version auf die aktuelle migriert.

# Danach ist v13 auf Port 5432 gestartet und v11 kann zur Kontrolle gestartet werden, diese läuft dann auf Port 5433. # Nach der Überprüfung kann der alte Cluster gelöscht werden:

pg_dropcluster [--stop] 11 main ##############################################################

Standardmäßig liegt das Datenverzeichnis ja unter /var/lib/postgresql/11/ bzw. .../13/

Wenn der Plattenplatz nicht reicht, würde ich postgres anhalten, den Inhalt von .../11/ auf die HDD auf eine freie Partition verschieben und dann an seinem alten Platz (.../11/) wieder mounten. Damit sieht das für postgres unverändert aus und du hast den Platz auf deiner Systemplatte wieder frei. Jetzt kann es beim Upgrade unter dem neuen Pfad .../13/ neben deinem HDD-Mount neu angelegt werden.

Wenn du genügend Platz auf der HDD hast, kannst auch eine zweite Partition unter .../13/ mounten und v11 als Backup noch aufheben, statt es mit pg_dropcluster zu löschen.

Für das Upgrade v13->v15 dann dasselbe Spiel noch einmal. Ob ein Upgrade von v11->v15 möglich ist, kann ich nicht sagen.

Export/Import funktioniert wahrscheinlich nur als SQL-Export. Die Binär-Formate lassen sich in einer abweichenden Version nicht importieren. .

Gruß Rico

Am 18.12.24 um 20:51 schrieb Luca Bertoncello:

Hallo Leute!

Ich habe einen Server, der noch mit Debian 10 lief. Vor ein paar Tage habe ich es auf Debian 11 aktualisiert und die nächste Tage wird die Aktualisierung auf Debian 12 gemacht.

Auf dem Server läuft PostgreSQL, vorher mit der Version 11, jetzt mit der Version 13, später die 15. Alles aus der Debian-Repos.

Das Problem mit der Aktualisierung ist, dass wenn ich pg_upgradecluster starte, werden die Daten von der alten Version in die neue _KOPIERT_. Und das geht leider bei mir nicht, denn die DB ist schon ~350GB groß und die Festplatte ist 500GB groß. Kein riesiges Problem: Export + Installation + Import funktioniert.

Nun hatte ich einen separaten Tablespace gehabt, auf den ich die "alte Version" der Datenbank verschiebe. Kurz gesagt: die Datenbank ist von OpenStreetMap und jedes Jahr mache ich den Rendering der neuen Karten. Weil ich komplett paranoid bin, halte ich noch die Datenbank des Vorjahres. Diese "alte Datenbank" wird auf einen Tablespace verschoben, der auf einer separaten Festplatte (kein SSD, wirklich eine etwas alte Festplatte für "nicht lebendige Daten") liegt.

Nun: als ich die Aktualisierung gemacht habe, habe ich nicht daran gedacht, auch die alte Datenbank zu exportieren. Ich dachte, ich könnte es irgendwie übertragen, aber bisher habe ich nicht den Weg dafür gefunden.

Ich habe den Tablespace angelegt mit

CREATE TABLESPACE oldgis_hdd LOCATION '/srv/oldGis';

Ich habe dann gesehen, das System hat eine Directory /srv/oldGis/PG_13_202007201/ angelegt. Ich habe keine Möglichkeit gefunden, die Daten von der alten Directory /srv/oldGis/PG_11_201809051/ zu kopieren, außer cp. Das habe ich gemacht und ich sehe zumindest, dass Postgres Daten sieht:

gis=# \db+ Liste der Tablespaces Name | Eigentümer | Pfad | Zugriffsprivilegien | Optionen | Größe | Beschreibung ------------+------------+-------------+---------------------+----------+--------+-------------- oldgis_hdd | postgres | /srv/oldGis | | | 325 GB | pg_default | postgres | | | | 348 GB | pg_global | postgres | | | | 559 kB | (3 Zeilen)

Allerdings die Datenbank, die in dem Tablespace "oldgis_hdd" ist, wird nicht gesehen.

Gibt es überhaupt eine Möglichkeit das zu "importieren" oder muss ich das als verloren deklarieren?

Tausend Dank Luca Bertoncello (lucabert@lucabert.de)