Update von MySQL z.B. unter XAMPP und auftretende Probleme und Fehlerquellen

Abgelaufen

MySQL Updaten z.B. in XAMPP/LAMP/WAMP Installationen

Von Zeit zu Zeit kommen Sie nicht umhin auch z.B. Ihre lokale Entwicklungsumgebung zu aktualisieren. Viele Websever nutzen PHP und hier findet laufend eine Ablösung von Versionen statt. Auf Webservern ist das meist durch den Hoster erledigt und dann kann ein Update mit wenigen Klicks aktiviert werden. Unter XAMPP / LAMP / WAMP etc. gestaltet sich das komplizierter, nicht nur weil man sich dort selbst drum kümmern muss, sondern weil es diese Updates meist nur als "Gesamtpaket" gibt, bei dem nicht nur PHP sondern auch MySQL aktualisiert wird. Das von Vorteil, weil auch bei MySQL hat sich sehr viel getan - allein schon der Umstieg auf MariaDB ist lohnenswert.

Nun, dass ist aber nicht der eigentliche Inhalt dieses Beitrags, sondern auf ein Problem einzugehen, welches beim Update von MySQL auftritt. MySQL zeigt sich hier sehr störrisch. Man möchte behaupten, dass eine Updatefähigkeit für MySQL nie vorgesehen war, so umständlich und widerspenstig verhält es sich.

Dieser Beitrag richtet sich an Lösungssuchende, die genau daran scheitern, eine bestehende langjährig gewachsene Entwicklungsumgebung erfolgreich und verlustfrei updaten zu wollen oder zu müssen. Ich selbst stand unter dem Zwang nach dem ich 4 Jahre nach Erstinstallation meiner XAMPP-Entwicklungsumgebung das neue CMS GRAVity ausprobieren wollte und feststellen musste, dass dieses nur unter PHP 5.6 läuft, was in meiner Umgebung nicht gegeben war.

Unerfahren und um nichts falsch zu machen oder gar Daten zu verlieren, hatte ich mich vorher belesen. Zu Updates findet man keine wirklich brauchbare Anleitung auf den apachefriends Seiten. Erst eine ausführliche Google-Recherche brachten Hinweise. Was die Bestandsdaten anbetrifft geht der Kern auf folgende Aussage: Die Daten aus den beiden Verzeichnisses xampp/htdocs/ und xampp/mysql/data zu sichern, dann die alte xampp-Installation zu deinstallieren und das neue Paket zu installieren. Abschließend werden die Proejekt-Bestandsdaten wieder in die gleichen Verzeichnisse verschoben - ohne überschreiben der vorhanden Installationsdaten. Für viele läuft das so, aber wer Joomla, Drupal oder Wordpress nutzt, wird ziemlich sicher Probleme bekommen. Bewaffnet mit obigen Halbwissen und zusätzlichem Backup, fühlte ich mich fit und sicher mein xampp-Verzeichnis mutig zu löschen. Es klang so einfach. Aber dann folgten 3 frustreiche unproduktive Tage, die ich damit verbrachte die Lavine an Fehlermeldungen zu verstehen und zu vermeiden, mehrfache De- und Installationswiederholungen und erneutes Scheitern, stundenlanges Lesen in Formen und Suchen nach Lösungen ...

Mit folgenden Fehlermeldungen werden Sie vermutlich konfrontiert:

#1932 - Table'dbxx-yy.zz_session doesn't exist in engine

Wenn man sich die Liste der Tabellen in PhpMyAdmin anschaut, dann sieht man hinter den InnoDB-Tabellen i.d.R. den Status 'in Benutzung'. Diese gehen nicht zu öffnene, weder über Struktur, noch über änder/bearbeiten-

13:47:00 [mysql] Fehler: MySQL wurde unerwartet beendet
13:47:00 [mysql] Ursache könnte ein geblockter Port, fehlende Abhängigkeiten,
13:47:00 [mysql] fehlende Berechtigungen, ein Absturz oder ein Abbruch einer anderen Methode sein.
13:47:00 [mysql] Drücke den Logs Button um error logs zu sehen und prüfe
13:47:00 [mysql] im Windows Event Viewer für weitere Hinweise
13:47:00 [mysql] Wenn du weitere Hilfe benötigst, kopiere den kompletten Inhalt des Log Fensters
13:47:00 [mysql] und füge ihn als Ergänzung in einem neuen Forum Eintrag hinzu. 

 

MySQL – InnoDB-Tabellen unter Joomla/Wordpress/Drupal:

Joomla und auch andere CMS wie Drupal und Wordpress nutzen zur Datenspeicherung neuerdings auch den Tabellentyp InnoDB, während früher fast ausschließlich MyISAM verwendet wurde. Projekte die früher angelegt wurden enthalten MyISAM-Tabellen und mit Migrationen dann auch InnoDB-Tabellen - wir haben dann also eine Durchmischung in den Tabellenformaten. Das macht auch Sinn, weil beide Formate Ihre speziellen Vorteile haben die nach Verwendungsziel genutzt werden sollten. Weiter Format kommen hinzu, die jeweil noch mal für speziellen Verwendungen geeignet sind.

Für InnoDB gibt es unter MySQL eine Besonderheit. Diese werden NICHT wie die MyISAM-Tabellen in den gesonderten Datenbank-Unterverzeichnissen abgelegt (z.b. mysql/data/dbxxyyzz/), sondern es gibt für das gesamte MySQL nur eine einzige Datei in der von allen Datenbank die InnoDB-Tabellen gespeichert werden! Bei der Sicherung der Projektdaten müssen also nicht nur die projektabhängigen Datenbank-Verzeichnisse gesichert werden, sondern ganz wichtig auch diese Sammeldatei im ~xampp/mysql/data/-Verzeichnis namens ibdata1. Adäquat muss bei einem Update von xampp dann anschließend auch diese Datei wieder mit zurückgeschrieben werden.

Anmerkung: In späteren Versionen von MySQL soll über eine config-Einstellung die Möglichkeit bestehen für InnoDB-Tabellen festzulegen, dass diese projektabhängig mit in die DB-Unterverzeichnisse gespeichert werden. Allerdings wird das mit Umkonfiguration nicht gleich automatisch mit erledigt, sondern muss durch Export- und Import-Aktionen explizit erledigt werden.

Das Problem bei einem Update besteht dann weiterhin darin, dass in der MySQL-Installation selbst auch schon InnoDB-Tabellen verwendet werden, so z.B. alle Tabellen in der Datenbank phpmyadmin und teilweise Tabellen in der Datenbank mysql. Folglich wird mit der XAMPP-Installation hierfür im mysql/data-Verzeichnis schon eine ibdata1 angelegt. Nun kann man also nicht einfach die o.g. ibdata1 aus unserer früheren Entwicklungsumgebungsinstallation mit den Bestandsprojekten und Ihren Daten hierher kopieren und überschreiben. Das führt nämlich dann dazu, dass die Projektdaten zwar wieder z.B. über den Zugriff über den Browser als z.B. Joomla-Projekte genutzt werden können, aber ein Zugriff über PhpMyAdmin eben nicht mgl. ist, so wie auch die Nutzung von PhpMyAdmin gestört ist, weil o.g. phpmyadmin-Tabellen in dieser ibdata1 falsch konstruiert sind.

Das Problem welches zu lösen ist, heißt also: Wie bekommt man die InnoDB-Tabellen der Updateinstallatation zusammen in eine Installation mit seinen alten Projekt-InnoDB-Tabellen, also zwei ibdata1 Dateien in eine MySQL-Installation?

Ein großes Problem besteht schlicht weg in der verfahrenden Situation, dass wenn PhpMyAdmin seine Tabellen nicht nutzen kann, in diesem nicht eine einzige Aktion durchführbar ist, ohne dass eine Fehlermeldung den Weg versperrt. Man hat also keine Chance über PhpMyAdmin irgendwelche nachträglichen Korrekturen an den eignen Projekttabellen vorzunehmen! Die Katze beißt sich in den eigenen Schwanz.

Hier nur als Vorschlag mehrere Lösungsangebot, die Sie abhängig von Ihrer Situation ausprobieren können.

Lösung 1:

Man könnte VOR(!) der ganzen Updateaktion seine eigenen Projektdaten einmal komplett als Dump exportieren und dann in die neue XAMPP-Installation wieder importieren. Das führt dann beide Datenbestände sauber in der ibdata1 zusammen. Bei mir fiel diese Verfahrensweise leider aus, weil:

  1. Ich wusste vor meiner Updateaktion nicht von diesen sich später erst offenbarten Problemen.
  2. Weiterhin wurde in allen Update-Anleitungen im Netz immer nur davon geschrieben, einfach die Daten auf Verzeichnisebene zu kopieren und dann wieder ins neue XAMPP-Verzeichnis zu kopieren. Warum hätte ich das anzweifeln sollen.
  3. Mein mysql/data-Verzeichnis enthielt ca. 40 Projekte, die ich unmöglich alle aufwändig exportieren wolle – warum auch lt. 1. und 2. gab es keine Grund für eine solche Monsteraktion? Also, ich hatte zwar von dem ganzen eine Sicherung, aber das Kind war schon in den Brunnen gefallen. Lösung 1 fiel also aus.

 

Lösung 2:

In allen Projekten die InnoDB-Tabellen z.B. in das MyISAM-Format umwandeln, weil diese dann sauber in den separaten Datenbank-Verzeichnissen liegen und es nicht zu den oben beschriebenen Konflikten aus den zwei ibdata1-Verzeichnissen kommt.

Leider fiel auch diese Option bei mir aus, weil für 40 Projekte die im Format durchmischten Tabellen umzuwandeln, war mir zu aufwändig und ist auch als Option schon hinfällig weil das vorher hätte passieren müssen.

 

Lösung 3:

Hier Schritt für Schritt:

  1. XAMPP installieren.
  2. Dann per PhpMyAdmin alle InnoDB-Tabellen in den beiden Datenbanken mysql und phpmyadmin in das Format MyISAM umwandeln (notieren welche das waren).
  3. Nun die eigenen Projektdatenbanken inkl. der ibdata1 ins mysql/data-Verzeichnis kopieren. Jetzt sollte zunächst erstmal alles perfekt laufen, sowohl die eigenen Projekte als auch die phpmyadmin-Aktionen.
  4. Anschließend sollten alle vorher umformatierten MyISAM-Tabellen der Ordnung halber wieder zurückgewandelt werden.
    In der mysql-Datenbank betrifft dies die Tabellen:
    • gtid_slave_pos
    • innodb_index_stats
    • innodb_table_stats
    • slave_master_info
    • slave_relay_log_info
    • slave_worker_info

Diese Lösung schien mir und in meiner Situation die praktikabelste, weil in der phpmyadmin-Datenbank handelt es sich um 19 Tabellen und in der mysql-Datenbank um weitere 6 (von gesamt 34 Tabellen) – also ein überschaubarer Aufwand.

Leider gibt es hierfür aber keine Vereinfachung, sei denn man schreibt sich ein SQL-ALTER-Script. Jede Tabelle muss einzeln geändert werden (Datenbank aufrufen, den Link Struktur für die Tabelle anklicken, im Tabellenmenü den Eintrag Operationen aufrufen, dort in der Gruppe Tabellenoptionen das Tabellenformat MyISAM einstellen und speichern).

Die richtige Vorgehensweise bei dieser Methode ist also zusammengefasst:

  1. Alte Daten-Verzeichnisse wie bekannt sichern
  2. Alte xampp-Installation löschen
  3. Neue xampp-Installation installieren
  4. Für mysql- und phpmyadmin-Datenbank die InnoDB-Tabellen im Format auf MyISAM ändern
  5. Die alten Prjojektdaten wie bekannt in Ihre Zielverzeichnisse kopieren inkl. der ibdata1.
  6. Jetzt müssten sowohl die Projektdaten und PhpMyAdmin selbst funktionieren
  7. Rückänderung der Tabellenformate für die mysql- und phpmyadmin-Tabellen.

 

Lösung 4:

Diese habe ich selbst noch nicht probiert sollte aber evtl. noch besser sein. In neue MySQL-Versionen soll es möglich sein, MySQL per Config so einzustellen, dass InnoDB-Tabellen nicht mehr in diese gemeinsame ibdata1 geschrieben werden, sondern jede Datenbank in ihr eigenes Datanbankverzeichnis.

Ich weiss wg. fehlender Selbstversuche allerdings nicht wann diese Umwandlung von zentral auf einzeln für die Datenbanken und deren Tabellen erfolgt. Muss das dann trotzdem noch jeweils einzeln erfolgen oder genügt diese eine zentrale Konfigurationsmaßnahme?

 

Wenn Ihnen dieser Beitrag geholfen und viel Zeit gespart hat, zeigen Sie sich erkenntlich: Über einen Klick auf Google+1 oder Rückmeldungen freue ich mich. Zeigen Sie mir, dass sich die Mühe für die Beitragerstellung gelohnt hat. Schenken Sie auch den Produktwerbungen Ihre Beachtung, denn damit wird mein Aufwand für diese Beiträge refinanziert.