von Maria-DB auf MySQL wechseln - wie würdet Ihr vorgehen?

  • Mein Webhoster (WebGO) überraschte mich mit der Mitteilung, dass bis spätestens Ende Februar keine MariaDB mehr verfügbar sei und ich meine Websites auf MySQL umstellen solle.

    Seit Januar bis jetzt läuft aber mein Umzug auf vollen Touren incl. meiner Praxis und deren Neu-Einrichtung. Nachdem die Telekom es fertig brachte, nach 8 Wochen einen halbwegs funktionierenden DSL-Anschluss herzustellen, kann ich ans Werk gehen. Verdammt knapp mit der Zeit!

    Aber wie gehe ich nun am effizientesten vor? Als erstes habe ich natürlich nochmals nach dem aktuellen Joomla-Update auf 3.10.6 ein Akeeba Backup erstellt und herunter geladen. Die beiden aktuellen Websites sind allerdings längst in die Jahre gekommen und sie müssen dringen auch inhaltlich voll überarbeitet werden. Eine gute Gelegenheit, auf Joomla 4 umzusteigen also. Aber aufgrund von Zeitmangel erst in frühestens 3 Monaten machbar.

    Meine erste Idee: Ich erstelle einen Dump der MariaDB (Export aller Tabellen im sql-Format) und lösche dann die Maria-DB. Dann lege ich eine neue MySQL-DB mit dem gleichen DB-Passwort und DB-Namen an und importiere den Dump. Anschließend müsste eigentlich die alte Site dann wieder laufen. – Aber was, wenn nicht?

    Zweite Idee: Ich erstelle ein neues Joomla-Installationsverzeichnis auf meinem Webspace und lege eine neue MSQL-DB an mit dem gleichen Passwort (aber leider zwangsläufig mit einem anderen DB-Namen). Anschließend lasse ich Kickstart die Site wieder herstellen und editiere dann in der configuration.php den Datenbank-Namen. – Aber ob das geht? Oder überschreibt mir Akeeba dann die bisherige MariaDB?

  • Hi Clemens,

    zum Datenbank Typ Umstieg:

    Einfach eine neue MySQL Datenbank erstellen, Zugangsdaten notieren.

    Die alte Datenbank exportieren im phpMyAdmin, das Ganze in die neue Datenbank importieren.

    Anschließend in die configuration.php die neuen Daten eintragen.

    host (falls anders)

    User

    Pw

    Db

    Sind die relevanten Zeilen.

    Und das war's dann auch schon.


    Das Joomla 4 Update machst du, wenn du wieder mehr Zeit hast, mit Ruhe in einer Testumgebung. Da kannst du dann mit Akeeba arbeiten, um die Kopie aufzusetzen.

  • Ende Februar ist in 4 Tagen, davon 2 Sa./So.

    Ganz ehrlich jetzt? Ich würde WebGo den Rücken kehren, mir einen anderen Hoster suchen und meine Website übernehmen lassen. Sicherheitshalber noch ein komplettes Backup anfertigen.

  • webgo ist auf jeden Fall performant.

    Wieso die größeren Hoster überwiegend generell solche 2 min Tasks nicht für ihre Kunden übernehmen (wenn sie's schon nicht automatisiert umstellen), sattdessen eine halbe Stunde im Support herumdiskutieren, wenn dann mal eine Frist überschritten wurde, habe ich noch nie verstanden.

    Datenschutz olé.

    Ich kann mir kaum vorstellen, dass das die erste Info zur Umstellung war.

  • Vielen Dank für eure schnellen und qualifizierten Antworten!

    Am 07.01.2022 informierte mich Webgo zum ersten Mal, dass "ab Februar 2022" MariaDBs abgeschaltet würden. Auf Nachfrage, warum, man dies machen wolle, wurde mir am 11.01.2022 geantwortet:

    Sowohl MariaDB als auch MySQL sind zwei wunderbare Datenbankverwaltungssysteme, es kommt hier auf den Use-Case an welches der beiden Systeme besser ist. MySQL ist grundsätzlich der Vorreiter, das heißt MySQL ist nach jedem Major Realease erst einmal eine lange Zeit performanter als MariaDB. Als wir die Entscheidung trafen uns ausschließlich auf MySQL zu fokussieren, war MariaDB in der Version 10.2/10.3 aktuell, welche zu dem Zeitpunkt mit MySQL in unserem Use-Case nicht mithalten konnte. Auf unsere Anfrage bei MariaDB ob sich dies wieder ändern würde, konnte man uns keine Antwort bzw Zusicherung tätigen, aus diesem Grund viel für uns die Entscheidung endgültig auf MySQL.Webgo meinte dann, dass man mit den Abschaltungen Ende Februar beginnen würde und gemäß meiner Anfrage meinen Server "zeitlich ganz nach hinten" setzen würde. Dabei wurde kein konkreter Termin genannt.

    Webgo hat einen extrem guten und schnell reagierenden Support. Dass man die Umstellung auf MySQL nicht als Service anbietet, zumal Webgo das Problem selbst geschaffen hat, finde ich allerdings fast schon frech.

    Die Erreichbarkeit meiner Sites liegt bei 99,8%, also nicht so toll (Websiteuptime.de). Die Ausfallzeiten können über den ganzen Tag verteilt auftreten und betragen meist zwischen 1 und 6 Minuten. In Preis-Leistungsverhältnis sehe ich Webgo als sehr günstig an.

    OK und jetzt mach ich die Änderungen der DBs.

  • Nun eine neue Schwierigkeit: Ich versuche, den Dump aus der MariaDB, den ich mit der Exportfunktion von PHP-MyAdmin gewonnen hatte, in die neu angelegte leere MySQL-DB zu importieren. Die zu importierende DB hat 25 MB Größe, ungezippt. Es dauerte ziemlich lange, dann kam die Meldung, dass die Laufzeit des Importscripts überschritten sei und ich die Datei einfach nochmals in die DB hochladen sollte, weil dann der Importvorgang dort fortgesetzt würde, wo er abbrach.

    Aber schon zu diesem Zeitpunkt gab es Fehlermeldungen, die ich im ersten Screenshot sicherte. Beim zweiten Anlauf wurde zwar der Import vollendet, aber mit Fehlermeldungen, deren Bedeutung und vor allem deren Fehlerbehebung für mich aktuell nicht möglich erscheint.

    Ich öffnete dann den Tab "Struktur" in PHP-MyAdmin und entdeckte erstaunliche Unterschiede in der Zeichencodierung, wie utf8_general_ci und utf8mb4_unicode_ci sowie als Typ des Datensatzes InnoDB und MyISAM. Vielleicht hängen die Fehler damit zusammen?

    Oder macht die MariaDB irgend etwas intern anders, als die MySQL, sodass eine Inkompatibilität entsteht?

    Anhängend die drei Screenshots. Vielleicht habt Ihr ja noch eine Idee, wie ich die Fehler beseitigen kann?

  • Warum machst du nicht ein Backup der kompletten Seite inkl.DB mit Akeeba.

    Danach mit Kickstart wiederhelstellen.

    Zuvor erstellt du eine neue SQL-DB und gibst Diese dann bei der Wiederherstellung an.

    MySQL und MariaDB sind doch fast identisch.

    So kannst du es ohne Probleme direkt in einer Sub-Domain testen.

    Mit HeidiSQL kannst du eine mariadb auch relativ einfach in SQL exportieren.

    Hier der Link zur portable version:

    https://www.heidisql.com/download.php?download=portable-64

    Infos hier:

    https://www.heidisql.com/

  • Oder probier's über SSH.

    https://www.webgo.de/hilfe/content/…forderlich.html


    Oder per adminer.org (andere 1-script db Verwaltung)

    Die sql bzw sql.gz kannst du, benannt als adminer.sql.gz auf gleiche Ebene legen wie die adminer.php.

    Und diese für den Import nutzen.

    So gibt's keine upload Probleme und generell habe ich damit eine weitaus höhere, fast lückenlose Erfolgsquote als mit den failconfigured PhpMyAdmins der Hoster.


    Entweder nur damit importieren oder exportieren und importieren.

    Wenn nix geht, verweise auf das Thema, schönen Gruß und sie sollen es dir bitte machen ^^

  • Hi, endlich hab ich den Umzug abgeschlossen und habe eure Tipps gelesen. Vielen Dank dafür. Mit der Webgo-Anleitung kam ich nicht zurecht, da mir das Verständnis dafür fehlt.

    Nun habe ich die Site mittels Akeeba Backup / Kickstart in einem neuen Verzeichnis meines Webspace wieder hergestellt und zuvor die DB als MySQL angelegt und von Akeeba füllen lassen.

    Resultat:

    Das Backend ist einwandfrei erreichbar, Änderungen lassen sich speichern. Minimale Anpassungen waren noch in der configuration.php betr. TMP- und Log-Verzeichnispfaden vorzunehmen.

    Frontend:

    Katastrophe! – Fehlermeldung:

    3685 - Illegal argument to a regular expression.

    ...

    Illegal argument to a regular expression. (https://lebenslust-jetzt.de/)

    Unter der o.g. URL könnt Ihr das Ergebnis nachvollziehen. Leider habe ich keine Vorstellung bzw. keinen Ansatzpunkt, wie ich jetzt weiter bei der Fehlersuche vorgehen sollte. Es gibt zwei Plugins, die schon mal Schwierigkeiten bereitet hatten und die ich versuchsweise deaktiviert habe, leider ohne Erfolg. Es handelt sich um BruteForceStop und um den JCH-Optimizer.

    Die htaccess habe ich sorgfältig geprüft. Da dort keine Fehler z.B. betr. Pfade oder Redirects enthalten sind, scheidet die auch aus.

    Hab die Ursache gefunden: SEOGLOSSARY war der Übeltäter. Nach dessen Deaktivierung läuft die Site wieder! Ja, das Teil arbeitet mit RegularExpressions.