Table definition has changed

google mal man 'mysql postgresql migration' oder so, es gibt einiges, bis hin zu Replikationslösungen, die von MySQL nach PG replizieren. Es gibt auch Firmen, die das kommerziell begleiten bzw. machen. Und z.B. ;-)

(ich sollte mal meine Signatur anpassen, um die neuen Realitäten diesbezüglich darzustellen ... )
 
Werbung:
Werbung:
Ora2Pg für mySQL habe ich noch nicht probiert. Vielleicht läuft es gut.

Ich würde einen anderen Weg präferieren. Ein SQL Dump.
Entfernen aller physikalischen Angaben aus dem Dump, also Engine Angaben usw.
Auch gleich explizite Indexangaben. Focus auf das logische Modell.
Auf Pg Seite eine konservative Anpassung der Tabellendefinitionen, also Datentypen.
Dann einen "Rohimport" und auf Fehler prüfen.

Dabei initial auf jeden Fall auf Dinge wie Collations, Codierung achten.
Außerdem zugleich das ganze Backtickgehampel wegmachen und die gängigen Verfahren bei Postgres nutzen. Ich würde plain ASCII Feldnamen verwenden, maximale Spaltennamen Länge beachten, fertig.

Ich kenne die Notation nicht, in der mySQL Kommentare für Tabellen und Spalten exportiert werden.
Diese sollte man aber entweder recht einfach per RegExp umformen können oder auch als Daten auslesen und diese Daten dann in Alter Table Statements für Postgres transformieren können.

Der "Rohimport" muss auf Datenkonsistenz geprüft werden. Mglw mit Compare Table Tools.
Ggf. müssen oder können Table Definitions anschließend optimiert werden.
Dann den Vorgang wiederholen. Das Wiederholen bedeutet, dass Du am besten alle Schritte durch Makros oder kleine Scripte wiederholbar durchführst und nicht irgendwo unreproduzierbar manuelle Arbeit ausführst.

Was wichtig ist und von @akretschmer geschrieben wurde. Konstruktionen im Datenmodell, die eigentlich ein Workaround sind, müssen nicht übernommen werden.* Dabei ist die Frage, was ein solcher Workaround ist, etwas schwierig zu beantworten, wenn man nur den alten Kram kennt. Anhaltspunkt: alles was andeutungsweise Daten redundant aussieht, ist schlecht und überflüssig. Paradebeispiel bei mySQL sind Temptables workarounds. Das ist natürlich kein fester Bestandteil des Datenmodells und dürfte demnach sowieso nicht in der Migration vorkommen, aber es beschreibt das Problem ganz gut. Es müssen ja keine Temptables sein, aber sie können so verwendet werden. Du wirst das wissen.

Am Ende sollen natürlich auch die Programme weiter laufen. Also etwas widersprüchliche Anforderungen.
Prio 1: Datentransfer 1:1
Prio 2: Optimierung

Die Optimierung kannst Du in der migrierten DB mit Bordmitteln (SQL) sehr problemlos und elegant Schritt für Schritt durchführen und Clientprogramme entsprechend nachziehen. Hier, in den Clients läuft im übrigen das meiste Zeug, was Du oft nicht brauchst, weil es in SQL häufig bessere und schnellere Wege gibt, als mühsame Erbsenzählerei im Client. Du wirst das wahrscheinlich sehen.

Am Ende prüft man die Indizierung und ergänzt dort, wo offensichtlich Bedarf ist. Dabei verwendet man dann die Indextypen aus dem PG Fundus, die sich am besten eignen. Zur Klarheit: Indizierung hat nichts mit Datenkonsistenz zu tun, dafür sind Constraints da, die PG einfach gut beherrscht. Indizierung hilft aber einem Constraint, schnell zu sein- je nach Constraint Art.
Wenn es um kleine Datenmengen geht, wo der Datentransfer innerhalb Sekunden oder Minuten abgeschlossen ist, ist auch die Indizierung kein Schwerpunkt in der Migration. Bei großen Datenmengen schon. Hier kann es sich wirklich lohnen, erst zu migrieren, dann zu indizieren.
Zu dem Problembereich zählt auch die Aktivierung von FK Constraints. Ggf. macht es Sinn, diese erst nach dem Datenimport einzuspielen. Hier würden sich dann u.U. Migrationsprobleme zeigen (oder Konsistenzprobleme aus dem Altsystem).

Das sieht vielleicht aufwändig oder sogar abschreckend aus. Aber es ist nun mal so, dass an der Stelle einfach viel gemacht werden kann oder vergessen, was man später "bedauert". Der Wechsel lohnt in jedem Fall.
Vielleicht ist Dein System so übersichtlich, dass es keine großen Stolperfallen gibt und vielleicht ist auch Ora2Pg so gut, dass es vieles von diesen Punkten bequem abfackelt, ist natürlich eine andere Herangehensweise.

Wenn Du irgendwo Hilfe brauchst, wirst Du die hier oder anderswo bestimmt bekommen. Es gibt viele hilfsbereite Postgres Kenner. Und es gibt gute Dokumentation zu jeder PG Version. Die aktuelle ist natürlich empfehlenswert, am besten unter Linux. Nicht dass es nicht geht unter Windows, aber Linux bietet einfach mehr Möglichkeiten, auch für Postgres.
Fang an und nimm Dir ein System und setz eine Datenbank auf und such Dir Tools, z.B. DBeaver. Baue Dir in Deinem Client eine Connection auf Deine pg db und probier etwas aus.

Aus der Erinnerung: Ein mySQL dump ist sehr "geschwätzig". Ich würde versuchen, das mittels Optionsschaltern schon so weit wie möglich einzudampfen Richtung purem SQL Daten Export. Weiß nicht, was da alles geht.

Ein weiterer Stichpunkt ist die Handhabung von Keys. Es ist eine Überlegung wert, nach dem Import die Key Definition der Tabellen zu ändern. Erst schlucken, was da ist, also keine Generierung von Schlüsselwerten. Dann nach dem Import mit Alter Statements die Schlüsselgenerierung verbessern. Ich würde Sequenzen nehmen und sie bei den Max Werten der Daten weiter laufen lassen.



* Wenn Du so was erkennst und es ist klar eingrenzbar und ein guter Teil des Migrationsaufwandes, dann lohnt es sich wahrscheinlich, das gleich wegzulassen und die Prioritäten an der Stelle zu tauschen.
 
Zurück
Oben