Migration 2.5.28 zu 3.5.1 Fehler bei upgrade

    Liebe Community,


    ich habe folgendes Problem und ich hoffe ihr könnt mir helfen (bin leider in diesem Forum nich fündig geworden und die gefunden Anleitung: https://forum.joomla.org/viewtopic.php?f=706&t=913699 hat mir auch nicht geholfen. Ich habe mein Joomla 2.5.28 (läuft auf php 5.6.30. , mysql 5.6.19) mit dieser Anleitung auf 3.5.1 upgraden wollen: https://docs.joomla.org/Joomla…Step_by_Step_Migration/de


    Beim durchführen des 9. Punkts in der Anleitung "write files directly" zeiget er mir nach kurzem arbeiten folgenden Fehler an:
    Index column size too large. The maximum column size is 767 bytes. SQL=ALTER TABLE `#__menu` ENGINE=InnoDB;


    Das Upgrade hat also nicht funktioniert, wenn ich wieder ins Kontrollzentrum gehe, sehe ich zwar das Kontrollzentrum von 3.x aber folgenden Fehler.
    Table 'db127335_23.#__postinstall_messages' doesn't exist SQL=SHOW FULL COLUMNS FROM `#__postinstall_messages`


    Habt ihr eine Lösung bzw. eine erprobte Lösung für mein Problem?


    Vielen Dank und liebe Grüße
    Andreas

  • Zum hilfreichsten Beitrag springen

    Ich habe dieses Problem auch schon gehabt. Der Grund war folgendes:
    - Die db war eine Mariadb
    - die Tabelle #__contentitem_tag_map hat einen Primärschlüssel mit einer Länge von 255 Bytes
    - Mariadb lässt für Schlüssel per Default maximal 767 Bytes zu
    - die Schlüssellänge wird bei utf8mb4_unicode_ci deutlich grösser als 1000 Bytes (4*255)


    Das führt dazu, dass die Erstellung oder Umwandlung der db and dieser Stelle abgebrochen wird. Angemeckert wird aber nicht die betreffende Tabelle, sondern die letzte die fehlerfrei geschrieben worden ist.


    Beim Updaten habe ich mir schon geholfen, indem ich die Schlüssellänge der betroffenen Tabelle (und es ist die einzige, die dieses Problem hat) reduziert habe, auf z.B. 180 Bytes. Danach läuft der Upodate fehlerfrei durch.


    Eleganter wäre es, wenn man in maria.ini ROW_FORMAT=DYNAMIC; setzen könnte, das lässt aber kaum ein Hoster zu (fragen lohnt sich aber).

    Wenn ein Server oder Webspace zickig sind, migriere ich Kundeninstallationen lokal auf meinem Rechner. Dazu habe ich mir ein XAMPP aufgebohrt. Wenn mir das gelungen ist, lade ich die Installation wieder auf den Server, in ein eigenes Verzeichnis, mit Subdomain, und prüfe dort die Funktionalität. Wenn das läuft, stelle ich die Domain auf das neue Verzeichnis, und nehme die alte Installation vom Server.


    Und wenn das nicht funktioniert, rate ich zu einem Hosterwechsel. Solche Probleme sind sehr selten, selbst bei 08/15 Hostern klappt das meistens ohne Probleme.

    Ok, aber da das Update nun deswegen fehlgeschlagen ist (hätte man vorher machen müssen und stand so nicht in der oben erwähnten Anleitung), werde ich wohl ein Backup aufspielen müssen, dann die Tabelle ändern und dann das Update gem. der Anleitung nocheinmal durchführen müssen?

    Hallo,
    also es hat nicht funktioniert. Ich habe die Tabelle #menu von utf8_general_ci auf utf8mb4_unicode_ci geändert. ode rmeinst du etwas anderes`? Warum gibts zu diesem Fehler keine anderen Infos/Lösungen/Anleitungen im Netz?

    Wie j!-n vorschlägt, alles lokal transferieren und dort entsprechend CurlY BracketS die maria.ini anpassen. Nach dem Upgrade kann man dann alles wieder online bringen.


    Oder aber die Schlüssellänge[!] der Tabelle anpassen, damit die Umstellung des DB-Zeichensatzes von utf8_general_ci auf utf8mb4_unicode_ci den Schlüssel nicht auf über 767 Bytes anwachsen lässt (4*256=1024).

    Zitat von xandreas

    Die Lösung war bei ber betreffenden Tabelle #menu die Länge des Primärschlüssels mit ALTER TABLE auf 200 zu verlängern,
    liebe Grüße xandreas

    Wird der Primärschlüssel in phpMyAdmin über AUTO_INCREMENT verändert? Oder vielleicht noch besser, wie lautet der ALTER TABLE Befehl?


    VG aus Berlin, Andreas