Datenbanken verschmelzen

Ich habe es nach einiger Zeit geschafft, eine Postgres8.4.6 Datenbank voll mit wichtigsten Daten auf die Version 13 über die Version 9.5.25 (postgresql-9.6.24-1-windows-x64.exe ginge mit --install_runtimes 0 im cmd) zu bringen. Leider wurde nicht alles übernommen, vorallem die ehealth-Datenbank (Speicherplatzmäßig die größte aber auch die jüngste Datenbank wegen der voluminösen KIM-Nachrichten) wurde komplett weggelassen. Postgresql 13 unter windows server 2012? Ich weiß jetzt auch den Fehler:

Das batch-Datei des Herstellers der Primärsoftware war nutzlos aber eine Vorlage, sich mit dumpall und dem Einspielen zu beschäftigen. Von postgres8 wird ein dumpall erstellt, in 9.5 eingespielt und von 9.5 wieder ein dumpall erstellt bzw. ab jetzt kann man das Skript benutzen, es installiert postgres13 und spielt den dump der Version 9.5.25 ein plus ein paar andere Konfigurationen.

Der Fehler war, dass ich die Fehlversuche nicht gelöscht hatte. Der Ordner /PostgreSQL13 inkl. /data hätten zumindest unbenannt werden sollen, deswegen gab es ja beim vorletzten Versuch lauter Fehler mit “… already exists”. postgresql - Is it possible to overwrite database records from dump? - Stack Overflow Ich hätte Postgres13 deinstallieren und den Ordner PostgreSQL13 zumindest umbenennen sollen, weil ja der relevante Teil /data nach einer Deinstallation erhalten bleibt.

Beim letzten Versuch habe ich besagten Ordner unbenannt, alles nochmal von vorne und … es ist zu 99 % perfekt. Konnte jetzt nicht alles testen, eine Fehlermeldung im Primärsystem verwirrt aber es geht alles, was auf dem alten System nicht ging aber gehen sollte (gehören zu den wichtigeren Funktionen).

Folgendes Problem: Seit Oktober wurde nun die Fehlerhafte Datenbank mit Daten gefüll. Mein Fehler war es, dass ich der Firma des Primärsystems vertraute und dachte, die würden sich früh melden und den Fehler korrigieren. Ein Fehler ließ sich durch Löschen(?) einer Datenbank reparieren, die Datenbank gehört zu einem E-Mail Programm, welches KIM-Nachrichten senden und empfängt. KIM-Nachrichten versenden ist wichtig, also füllte ich das Programm aus und… es funktionierte nicht, fehler in der Datenbank. Sowas hatte ich schon November 2021 weil ich so viel mit dem Programm gearbeitet habe, bis die Datenbank den Dienst verweigerte. Der Hersteller schaltete sich kurz darauf ein, reparierte die Datenbank, ich füllte wieder die POP3 und SMTP Daten in das Programm und es lief alles geschmiert. Ich dachte, die würden das wieder machen => Fehlanzeige!

Seit Oktober wird dann also die Fehlerhafte Datenbank gefüllt, weil ich naiv war und dachte, die Firma wird schon zumindest an diesem Punkt der Datenbank helfen. Dummer Fehler.

Die Zeit verging und ich besorgte mir eine SSD.

Festplatten sind bekanntlich langsam und ich wollte nicht wieder Zeit verschwenden wegen dumpall und einspielen. Also klonte ich die Festplatte auf die SSD und begann nochmal von Null. dumpall von der 9.5.25, einspielen in postgres13.12 und… es ist alles zu 99 % perfekt (gestern Abend die Grundfunktionen getestet). Problem bei dem ich jetzt hilfe benötige: Die Daten sind alt und die Daten seit dem 03.10.2023 sind nicht in der guten postgres13 Datenbank auf der SSD. Hingegen sind praktisch alle Daten im postgres13 auf der Festplatte, nur die ehealth-datenbanken sind ganz leer. Wie kann man die daten von postgres13 der Festplatte auf postgres13 auf der SSD übertragen?

Eine Möglichkeit, die ich der Praxis sagte war, einfach neu eintippen, heißt, postgres13 festplatte starten, alle dokumente ein termin-einträge drucken, notizen anfertigen. Dann postgres13 SSD starten und alles reintippen. Geht das auch eleganter? pg_restore oder so?

Ich hätte zumindest die postgres 9.5.25 datenbank weiterfüllen lassen sollen, es war falsch von mir, in einer fehlerhafen DB Daten schreiben zu lassen. Mein Problem war die Frist, die die Firma setzte, weil in Kürze nur noch postgres 13 supported wird.

Nur zur Info: Das Primärsystem funktioniert nicht mit postgres14-16. Ich versuchte eine Datenbanksicherung mit postgres16 IM primärsystem (weiß nicht genau was da passiert ein paar megabyte werden da geschrieben): es kommt zu einem fehler, welches m. M. n. der postgresversion14-16 geschuldet ist.

Sorry, das ist zu konfus. Der Kunde hat mit der Datenbank irgendwelchen Unsinn gemacht, Sie auch, und jetzt soll irgendwas repariert werden.

Ich würde einen Spezialisten an Bord holen.

Zur konkreten Frage, wie man eine Datenbank von einer Platte auf eine andere überträgt: das kommt darauf an, ob es sich tatsächlich um eine Datenbank handelt oder um einen ganzen Datenbank-Cluster.

  • eine Datenbank kann man nur mit Dump/Restore übertragen

  • bei einem ganzen Cluster kann man PostgreSQL stoppen und einfach das Datenverzeichnis kopieren - aber nur dann, wenn auf beiden Seiten dasselbe Betriebssystem läuft (wenn die C-Library eine andere Version hat, muß man möglicherweise einige Indexe neu erstellen)

Einfach gesagt ist es so passiert:

August 2023: postgres8.4.6 auf postgres13.11 portieren (dumpall und einspielen), fehlgeschlagen, Datenbank nutzlos. Weiter auf postgres8.4.6 schreiben (hätte hier postgres13.11 und vorallem postgres13.11/data löschen müssen)

Anfang Oktober 2023: postgres8.4.6 auf 9.5.25 portieren, dann von 9 auf 13.12 (zu dem Zeitpunkt hat postgres die Version 13.12 veröffentlicht und ich sagte mir, warum auf 13.11 weiterhin setzen, habe auch Ende Oktober 2023 auf dem privaten Rechner getestet, ob so Sachen wie Dienstname in Windows oder Pfade, die Datenbanken erhalten bleiben, würde mit 13.11 alles laufen und man installiert später das Minor Release 13.12, und ja, der Installer macht das richtig gut) ==> Das PVS startet gut, aber eine große Datenbank, die größte (eHealth) fehlt, was bedeutet, dass die Migration zwar klappt, das Skript absoluter Murks ist und erst ab dem dumpall von postgres9 klappt UND dass /data von postgres13.11 nicht überschrieben wird! das hätte ich wissen sollen. oder zumindest postgres13.11 löschen, insbesondere dessen /data löschen, dann nochmal sauber von postgres9 auf postgres 13.12 das dumpall ziehen.

Der Amateur, der das Skript schrieb, schrieb auch im step 7 des Batch-Skripts:
set VALUE_NAME=Path
set VALUE_VERSION=Version
set NEW_NAME=%pg13_path%
set NEW_VERSION=13.11.1

Als ob postgres seit Version 10 weiterhin 3 Versionszahlen schreibt,
dabei schreibt postgres ausdrücklich, dass es nur noch 2 Versionszahlen gibt (Major/Minor):
Starting with PostgreSQL 10, a major version is indicated by increasing the first part of the version, e.g. 10 to 11. Before PostgreSQL 10, a major version was indicated by increasing either the first or second part of the version number, e.g. 9.5 to 9.6. PostgreSQL: Versioning Policy Wahrscheinlich war er/sie durch die -1 im Dateinamen (postgresql-13.11-1-windows-x64.exe) irritiert oder weil mehr als 90 % der Kunden der PVS-Firma postgres Version <10 verwendet haben (3 Versionszahlen und Minor Release die 3 Zahl) und bis Ende 2023 alle auf 13 wechseln müssen.

Und sturr ist die Firma alle mal. von 9 auf 13 geht, von 8 auf 13 geht nicht, will die Firma nicht einsehen. Dachte auch dass durch die 3 Wochen fehlender Daten der Kunde mich auseinander reißt, wobei der Fehler passt gut zum Streit im August 2023. So heftig bedroht wurde ich schon lange nicht mehr.

Also doch kein Problem mit Festplatten. Die Kunst einer brauchbaren Problembeschreibung ist, das Unwesentliche wegzulassen, aber nichts Wesentliches auszulassen.

Ich glaube zu verstehen, daß es sich um ein „Split Brain”-Szenario handelt, daß also in beide Datenbanken geschrieben wurde und sie auseinandergedriftet sind. Für den Umgang damit gibt es keine einfache automatische Möglichkeit. Man muß mehr oder weniger händisch die neuen Daten aus der einen Datenbank herausholen und in die andere einfügen. Möglicherweise gibt es Kollisionen bei automatisch erzeugten Primärschlüsseln, die man entsprechend ändern muß.

Eine einfachere Lösung wäre, eine der Datenbanken zu verwerfen und den Datenverlust in Kauf zu nehmen.

Ja. In die Datenbank auf der Festplatte wurde bis zum 27.10.2023 weitergeschrieben, obwohl mehrere Tabellen und Sub-Datenbanken defekt sind (aus Unkenntnis von postgres-Migrationen und dem schrottigen Skript des Schrott-Unternehmens) und in die Datenbank auf der SSD ist der Stand vom 03.10.2023 und wir sind dabei alles händisch zu kopieren mit Screenshots.

Selbst wenn ich das fehlerhafte postgres13.11 auf der festplatte vor dem 04.10.2023 deinstalliert hätte, hätte ich nie gewusst, dass man insbesondere /data löschen muss. denn das war der relevante und vorallem fehlerhafte ordner. wir hätten entweder auf postgrrs 8.4.6 weiterschreiben sollen, bis ich die migration sicher verstand, dann auf 9.5.25 migrieren und schnell weiter auf postgres 13.12. oder auf postgres 9.5.25 bleiben, das klappte ja gut, weil ich an jenem 3.10. abend keine zeit mehr fand postgres 13.11 zu löschen, und am 04.10. wurden wieder daten geschrieben. ich hatte gehofft, dass die firma die datenbanken repariert denn an einer kleinen stelle der für dem email-verkehr war, da hatten wir einen fehler, den wir schon 2021 hatten und der war leicht zu lösen. aber die firma stellte sich taub und stumm (großer kundenstamm).

Ich wusste so wenig von postgres, dass ich nichtmal verstand, was mit datenbanken anderer Programme gemeint war. das heißt nämlich, dass man den pfad für postgres selbst bestimmen kann, wichtig ist, dass postgres als windows-dienst im hintergrund läuft, damit andere programme postgres finden und darauf daten schreiben können.

will garnicht wissen, wie das jetzt bei anderen dbms’en ist… :face_with_diagonal_mouth:

PostgreSQL: Roadmap

wad auch fast so wichtig ist PostgreSQL: Versioning Policy

So, ich mach jetzt hier zu. Das Ganze ist nicht wirklich zielführend. Wenn es konkretes Problem besteht, dann schreibt einen entsprechenden Thread und nicht nur halbe Sachen. Ein Link auf Roadmaps etc. bringen einen hier nicht weiter…

3 „Gefällt mir“