MySQL 5.1.x zu 8.x migrieren oder anders vorgehen?

He[I]nz

Benutzer
Beiträge
22
Hallo,

bräuchte einmal eure Hilfe.:)

Wir wollen eine Open Source Anwendung nutzen, von welcher auch der Quellcode öffentlich zugänglich ist.
Um welche Software es genau geht soll hier unwichtig sein.😳

Diese Software verwendet als DB (leider) noch MySQL 5.1.x.
5.x deshalb, weil damit nur MyISAM möglich ist und das für Schreibzugriffe wohl schnell sein soll (was gewollt ist).
Der Nachteil von MyISAM ist dann aber die Lesegeschwindigkeit, da wäre InnoDB schneller.
Diese Software gibt es auch käuflich zu erwerben, dann wäre ein MySQL mit InnoDB vorhanden.
Ein weiterer Nachteil der Software, welche aber vernachlässigbar ist: Dies Software läuft nur unter Windows.

Um nicht zig DB-Systeme laufen zu haben würden wir gerne die 5.1 (samt MyISAM) irgendwie auf ein MySQL 8.x "migrieren" oder was auch immer um folgendes zu erreichen:

Entweder:
-MySQL 5.1.x (MyISAM) bleibt als Haupt-DB (für Schreibzugriff; CREATE, INPUT, DELETE, ALTER...) erhalten und in eine MySQL 8.x kommt eine "automatische Migration" (Dump per Skript; Mit Anpassung für InnoDB), so dass diese MySQL 8.x DB nur für Lesezugriffe (SELECT) herhalten soll.
Für dieses Szenario müsste dann der Sourcecode von einem Dritten angepasst werden (da ja zwei unterschiedliche DB's angesprochen würden).

Oder
-MySQL 5.1.x (MyISAM) wird komplett durch MySQL 8.x (InnoDB) ersetzt, mit dem Nachteil, dass Schreibzugriffe dann langsamer wären, aber Lesezugriffe schneller -> Keine Anpassung am Sourcode notwendig.
-MySQL 5.1.x (MyISAM) wird komplett in MySQL 8.x übernommen (also auch als MyISAM) und dort zusätzlich (automatisch; per Dump-Skript) eine Kopie als InnoDB angelegt -> Hierbei muss am Sourcecode aber widerrum durch einen Dritten eine Anpassung vorgenommen werden, da auch hier 2 unterschiedliche DB's.

Eine Replikation fällt flach, da diese ja nur ab 8.x funktioniert.
Also MySQL 8.x Master und MySQL 5.x Slave würde gehen, aber eben nicht 5.x Master und 8.x Slave.

Jede Idee, welche nicht zu komplex wird, einfach umzusetezn ist und uns kein extra Geld kostet (also keine Cloud etc.), ist willkommen.


PS: Was könnte von MySQL 5.1.x verwendet werden was in MySQL 8.x nicht mehr vorhanden (deprecated) ist?
Inkonsistenz soll zwar vermieden werden, so dass die Anwendung voll funktionsfähig bleibt, aber schneller Lesezugriff (durch InnoDB) gewährleistet werden.
 
Zuletzt bearbeitet:
Werbung:
MySQL 5 ist ein absolutes No-Go. Veraltete, ungewartete Software einzusetzen ist ein Sicherheitsalbtraum.

Ein aktuelles Mysql wenn dann mit InnoDB, falls es die Software auch wirklich unterstützt.
 
eine aktuelle MySQL mit Blackhole-Engine dürfte beim speichern schneller als eine 5er mit MyISAM sein und beim Lesen auch überragend schnell sein...
 
Ist es für die Anwendung nicht transparent, welche DB Engine verwendet wird?
Ist MySql 5.1 eine Empfehlung oder Voraussetzung? Ist die Anwendung dann evtl. genau so alt?
 
@Walter
Hilft mir leider nicht weiter.🤨

@akretschmer
Dachte Blackhole wäre nur zum Testen?!:eek:

@Dukel
Ist doch transparent(!), MySQL 5.1.51 (laut mitgeliefertem installierten Verzeichnis).
Die Anwendung ist nicht genau so alt.;)
Es gibt eine "nur" etwas neuere Version der Anwendung die dann allerdings kostenpflichtig ist (wird nicht benötigt!:rolleyes:).
MySQL v5.x ist nicht "zwangsweise" Voraussetzung (für Leute die sich etwas auskennen), wird aber mitgeliefert und es gibt keine Garantie, dass alles reibungslos mit einer neueren MySQL-Version läuft (obwohl ich denke, dass es keine Probleme geben sollte).
MyISAM wird halt eben nur von der Open Source Version (offiziell) unterstützt, während in der kostenpflichtigen InnoDB benutzt wird.
Man will (logischwerweise) die kostenpflichtige Version vertreiben.:rolleyes:
 
MyISAM ist radioaktiver Sondermüll aus dem letzten Jahrtausen, sowas will man nicht mehr einsetzen. Wenn die Software OpenSoure ist, würde sie nichts kosten, da muß ein "Mißverständniss" vorliegen. Blackhole kann man auch 'produktiv' nutzen, wenn man bei einem SELECT nichts erwartet ;-) Und denke bei MySQL NIE, daß etwas, was mit einer SEHR alten Version lief, mit einer aktuellen Version läuft. Zum Teil basiert viele Software darauf, bewußt Bugs in MySQL auszunutzen. Das scheppert dann bei aktuellen Versionen.

Viel Spaß damit!
 
Ohne die Software zu kennen -die ja hier egal sein soll- ist die Frage etwas sinnlos.
Welche Software rechtfertigt den Einsatz einer verbugten DB aus der Steinzeit?

Glaskugel:
Wenn es OS ist, basierend auf uraltem mysql, dann ist der "Hersteller" offenbar nicht in der Lage (sehr klein) oder willens (.. dazu fällt mir kein netter Klammerbegriff ein), etwas anderes anzubieten.

Es mag exotische Bereiche geben, wo man um solche Konstellationen nur schwer herum kommt. Gegen "viele Betriebssysteme" kann man sowas wie Docker, .. einsetzen.

Und wenn der Source Code (vor allem DML und DDL) bekannt ist, dann kann man sich das auch mal ansehen und eine qualifizierte Annahme dazu treffen, wie risikoreich das ist, der Einsatz selbst oder auch der Einsatz einer nicht unterstützen, "neuen" Version von mySQL. Ich mache sowas auch, mein Lieblingsauto ist über 20 Jahre alt und es fährt sehr gut und sparsam. In der Werkstatt rollen die Leute aber mit den Augen und es wird teuer, seit es keine Ersatzteile mehr gibt.

Dir auch einen guten Rutsch!
 
Ein gutes Neues euch allen!🤗

Wir schweifen vom eigentlichen Thema ab!😉

Der Hersteller/Entwickler möchte ja die neue kostenpflichtige Version vertreiben, welche schon mit MySQL 8.x läuft.
Die "ältere" Version soll wohl nur die Kunden auf den Geschmack bringen, hat aber auch den vollen Umfang, bis auf Neuerungen welche wiederum nicht benötigt werden und ein etwas moderneres Design (drauf gepfiffen🥱).

Zum Teil basiert viele Software darauf, bewußt Bugs in MySQL auszunutzen. Das scheppert dann bei aktuellen Versionen.
Somit glaube ich auch nicht, dass der/die Entwickler da irgendwas in diese Richtung gemacht haben .


Natürlich, wenn man sich auskennt, kann man sich den Sourcecode ansehen, um zu verstehen was da wo gemacht wird - tun wir leider nicht, da wir die Programmiersprache nicht können.

Wenn niemanden zum weiteren Vorgehen etwas einfällt, dann würde mich zumindest die Antwort zum ersten Satz meiner "PS"-Frage von oben interessieren.

Danke!🙂
 
Wenn niemanden zum weiteren Vorgehen etwas einfällt, dann würde mich zumindest die Antwort zum ersten Satz meiner "PS"-Frage von oben interessieren.
Bugs wie z.B. Abfragen mit Aggregationen, wo nicht alle Spalten im Result entweder aggregiert oder gruppiert werden. MySQL ändert auch mal in Minor-Versionen grundlegendes Verhalten - sprich Version x.y.z -> x.y.z+1 ändert Verhalten -> Applikationen fallen auf die Nase.
 
Werbung:
Letztendlich muß das der Hersteller Deiner Software machen. Wenn der unwillig oder unfähig ist und/oder ihr mit der Software unzufrieden seid - so wechselt die Software. Wenn ihr dabei bei der Wahl der unterliegenden Datenbank auf Qualität achtet, bringt das ein Plus an Zukunftssicherheit.
 
Zurück
Oben