Update/Migration von Postgres 9.6

Hallo, ich bitte um einen architektonischen Ratschlag. Unsere Applikation fährt derzeit 12 Datenbanken (Gesamtgröße ca. 32 GB gemäß \l+) unter PostgreSQL 9.6. Für die neue Applikationsversion müssen wir PostgreSQL upgraden auf irgendeine PG-Version zwischen 10.x und 14.x.
Unsere Präferenz wäre 11.x, weil wir schon ein andere PostgreSQL-Instanz unter dieser Version fahren. Das ist jedoch nicht erzwungen.
Unsere beiden existierenden PG-Instanzen laufen auf demselben CentOS 7.9-Server. CPU-, RAM- und Storage-Erweiterungen wären kein Problem, falls notwendig.
Was ist jetzt für uns das sinnvollste Vorgehen, wenn die Einfachheit von Migration und späterem Operating das wichtigste Kriterium ist?

  1. Die 12 Datenbanken von der 9.6-Instanz in die existierende 11.x-Instanz zu migrieren?
  2. Oder ein In-Place-Upgrade der 9.6er-Instanz auf 11.x (oder 12.x oder 13.x oder 14.x)?
  3. Oder eine neue PG-Instanz mit 12.x, 13.x oder 14.x erstellen und die 12 Datenbanken dort hinein migrieren?

Genügen diese Infos für eine Antwort? Welche Information wird sonst noch benötigt?
Danke für jegliches Feedback.

alles hat seine Vor- und Nachteile. 12 Datenbanken zusammen 32GB klingt aber jetzt eher nicht als groß. Beachte, daß in weniger als 11 Monaten dann Version 11 aber auch ausläuft. Wenn Du also eine neue Instanz mit 14 hinstellst und dann Schritt für Schritt via pg_dump von 14 aus die alten sicherst und den Dump einspielst hast Du auch immer noch eine Fallback-Lösung. Das würde ich also, mit meinem begrenzten Wissen zu Deiner Situation, wohl bevorzugen

Die 11er hat in rund 11 Monaten auch ihr Ende erreicht, solltet ihr auf 14 migrieren (ich persönlich würde gleich auf 15 gehen - aber das hast Du ja explizit ausgeschlossen - warum eigentlich?)

Die Migration würde ich mit pg_upgrade machen - damit wird das komplette Cluster (=Instanz) in einem Rutsch migriert. Bei nur 32GB geht das auch recht flott.

1 „Gefällt mir“

Die zentrale Frage bezueglich der Zielversion: Hast Du Tables in 9.6, die mit OIDS = TRUE definiert wurden? Wenn ja, dann wird die Migration in ein PG > 11 etwas kniffliger, weil OIDS ab PG12 nicht mehr unterstuetzt werden.

Migrieren kann man die Tabellen soweit ich weiß schon. Die oid Spalten sind halt dann nicht mehr versteckt.

Klar kann man, man muss ihre Werte halt in eine neue, explizite column “temp_oid” (oder so) ueberfuehren, die man in der Zielinstanz nach pg_dump oder logischer Replikation wieder in “oid” umbenennen muss, falls die Anwendungen mit oids operieren. Ansonsten sind sie weg!

Aber wie gesagt: den Zirkus hat man nur, wenn man von dieser unsaeglichen Option “OIDS=TRUE” Gebrauch gemacht hat.

OK, da habe ich mich wohl geirrt. pg_upgrade bricht dann mit folgender Fehlermeldung ab:

Your installation contains tables declared WITH OIDS, which is not
supported anymore.  Consider removing the oid column using
    ALTER TABLE ... SET WITHOUT OIDS;
A list of tables with the problem is in the file:
    tables_with_oids.txt

Vielen Dank für alle Beiträge und Antworten. Sie haben uns weiter geholfen.
Wie üblich bei kommerzieller Software gibt die Applikation vor, welche DB-Versionen unterstützt werden, und diese Liste schließt nur die PG-Versionen 10 bis 14 ein.
Wir gehen im Augenblick zuversichtlich davon aus, dass keine OID-Columns verwendet werden, werden das aber noch genauer prüfen.
Mir persönlich wäre es am liebsten, die Zahl der Instanzen zu reduzieren und somit die 12 obigen Datenbanken unserer 9.6er-Instanz in die bestehende 11er-Instanz zu migrieren. Dann könnte man in einem späteren, zweiten Schritt den 11er-Cluster z.B. auf 14 upgraden. Das müssen wir aber noch im Team diskutieren.
Ich habe noch nicht verstanden, ob ich für die Migration unserer 12 Datenbanken unter 9.6 in die 11er-Instanz auch pg_upgrade nutzen kann, oder ob pg_upgrade voraussetzt, dass der neue Cluster “leer” ist.
Kann das jemand sagen?
Zumindest müssten wohl User/Roles detailliert geprüft werden, um ein Überschreiben zu vermeiden, wenn derselbe Username sowohl im alten als auch im neuen Cluster schon verwendet wird. Korrekt?

Ja, das Ziel-Cluster muss leer sein (also nur initdb gelaufen, sonst nichts).

Das geht dann nur via pg_dump und pg_restore (pro Datenbank, lässt sich aber recht einfach skripten). Achtung: verwende auf jeden die Binaries der 11er Version dafür!

Ja, Benutzernamen gibt es nur einmal im Cluster. Wenn es also die gleichen Benutzernamen gibt, diese aber unterschiedliche Rechte haben sollen, dann müsst ihr beim Import das mit einem anderen Benutzernamen machen. Ich empfehlepg_restore mit der Optionen --no-owner laufen zu lassen, damit ihr beim Import dann keine Probleme mit den Benutzernamen bekommt. Vielleicht macht --no-privileges auch Sinn, das hängt aber von eurem Rechtekonzept ab.

Super! Vielen Dank für die Erklärung!