MySQL-Wechsel von 4 auf 5

[RolandG]

Ich möchte einen schon länger bestehenden Blog aus einer alten Server-Umgebung in eine neue umziehen. Dazu gehört, einen Dump der Datenbank unter MySQL 4.0 in eine Datenbank unter MySQL 5.6 zu importieren.

Bei diesem Versuch erhalte ich zunächst die Fehlermeldunge

Code: Select all

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 20 

Die kann ich eliminieren, indem ich an allen vorkommenden Stellen „TYPE=MyISAM“ durch „ENGINE=MyISAM“ ersetze.

Danach kommt der Import an die Stelle "last timestamp(14) NOT NULL," unter "CREATE TABLE prefix_suppress". Da moniert MySQL, dass die Genauigkeit zu groß ist ("Too big precision 14 specified for column 'last'. Maximum is 6.")

Wenn ich die „14“ in „6“ ändere, läuft der Import sauber durch. AAAABER: Das kann ich doch sicher nicht einfach so machen. Deshalb meine Frage:

Wie macht man es an dieser Stelle korrekt?

Danke vorab!

[Timbalu]

Das ist keine normale Einstellung der timestamp Spalte. Sie ist immer "last timestamp NOT NULL".
http://stackoverflow.com/questions/1170 ... -time-maxi Am besten du schaust noch einmal nach, wer dir da beim Export solche Sachen hineinschreibt.

PS. Am besten wäre es IMHO komplett neu zu beginnen (Neuinstallation) und dann vielleicht auch gleich mit UTF-8 und utf8_unicode_ci Kollationen zu arbeiten. Dies würde wahrscheinlich einen korrekt übersetzten UTF8 Export deiner vorherigen Table Daten erfordern. Und natürlich alles weiter laufen zu lassen, bis die Migration vollstandig gelungen ist. MySQL 5.6 ist übrigens sehr schnell und eine wesentliche Erleichterung, und das schon gegenüber den 5.5 Versionen.

[RolandG]

@ Timbalu: Vielen Dank für deine ausführliche Antwort! Du meinst, Serendipity neu installieren und dann in der Neuinstallation über "Wartung" -> "Daten importieren" -> "Serendipity" die alten Daten importieren. Dann mache ich das!

[Timbalu]

Nein. Das meinte mein Post Scriptum nicht. Ich hätte PhpMyAdmin oder soetwas dafür benutzt und jeden nötigen Tabellensatz einzeln migriert. Gerade weil du ja in diesem Fall nur die Daten und nicht Struktur willst und dabei noch den Charset 'Export als' - 'Import als' Migrator benötigst. Das wir so ein Tool Importer auch für Serendips haben ... habe ich noch nie getestet. Der ist auch eher für Gleich zu Gleich gedacht!
Ein eventuelles Umstellen auf UTF-8 ist zu empfehlen, kann aber durchaus Probleme machen und etwas Zeit und Mühe beanspruchen. Die Frage ist ja eher, ob das überhaupt dein Charset Fall ist?
Möglich ist auch, dass einzelne Tabellen zwischenzeitlich verändert wurden und ein Import oder Daten ohne zusätzlichen Aufwand eventuell nicht so einfach möglich ist. Es kommt also auch darauf an, von welcher Version du migrierst. (Solange das von 1.5 an aufwärts ist, sollte das aber eigentlich kein Problem sein.)

PS. BTW, Hast du deine Joomla Integration gelöst?
PPS. Es gibt auch noch diesen eventuellen Fallstrick bei Mysql4 auf 5 Migrationen: http://board.s9y.org/viewtopic.php?f=10&t=19626

[RolandG]

@ Timbalu: Puh, das ist ja eine unendliche Geschichte...

@ ALLE: Gibt es jemand, der das kann und mir ein Angebot machen möchte?

@ Timbalu: Du dem PS: Nein, es hat sich bei den Joomla-Leuten leider niemand gefunden. Ich mache es jetzt erst einmal so, dass ich den Blog separat laufen lasse und ihn einfach über einen Link aufrufbar mache. Er öffnet dann in einem eigenen Fenster mit einem angepassten Design. Wenn der Blog denn dann einmal in einer aktuellen Umgebung läuft...

[RolandG]

GELÖST:

Das "last timestamp (14) NOT NULL," führt ja zu der Fehlermeldung, dass das Feld zu lang ist und höchstens 6 lang sein darf. Ich ging davon aus, dass ich bei einer Reduktion auf 6 etwas abschneide und habe das dann gelassen. Allerdings ist timestamp - wie Timbalu auch schreibt - eigentlich ja eindeutig und sollte ganz ohne Längendefinition auskommen. Und siehe da: Wenn ich das "(14)" weg lasse, wird die Tabelle sauber angelegt und timestamp korrekt übernommen.

[garvinhicking]

Kleiner Nachtrag: Ggf. lohnt es sich sonst die SQL Dumps via mysqldumper oder adminer zu erstellen. Dort kann eine Syntax benutzt werden die auch für MySQL 5.6 gültig wäre...

LG;
Garvin

[RolandG]

@ garvinhicking: Ja, MSD ist immer ein guter Tipp! Speziell in diesem Fall hatte ich leider nur keinen Zugriff auf den Server, sondern nur einen Dump vom Betreibr bekommen, der über die Konsole erstellt wurde.

[RolandG]

So, jetzt habe ich nach einer halb automatisierten / halb manuellen Übernahme alle Daten in einer frischen Serendipity-Installation am laufen - und es sieht alles gut aus! Danke für die Hilfe hier!

Es hakt alledings noch an einer Stelle: Bei Neuanlage eines Benutzers oder bei der Änderung von Daten eines vorhandenen Benutzers (zum Beispiel neues Passwort oder Sprache) erscheint die Fehlermeldung:

Code: Select all

1Duplicate entry 'userlevel' for key 1Duplicate entry 'email' for key 1Duplicate entry 'lang' for key 1Duplicate entry 'wysiwyg' for key 1Duplicate entry 'wysiwygToolbar' for key 1Duplicate entry 'mail_comments' for key 1Duplicate entry 'mail_trackbacks' for key 1Duplicate entry 'no_create' for key 1Duplicate entry 'right_publish' for key 1Duplicate entry 'simpleFilters' for key 1Duplicate entry 'enableBackendPopup' for key 1Duplicate entry 'moderateCommentsDefault' for key 1Duplicate entry 'allowCommentsDefault' for key 1Duplicate entry 'publishDefault' for key 1Duplicate entry 'showMediaToolbar' for key 1Duplicate entry 'use_autosave' for key 1

Angelegt wird der Benutzer in der Tabelle "authors", aber nicht (wie bei einer normalen neuen Installaton) in der Tabelle "config". Wie kann ich das korrigieren?

Und noch etwas: Bei der Neuinstallation von Serendipity wird in der Tabelle "authors" das Feld "hashtype" angelegt. Das gab es in meiner alten Installation noch nicht. Was muss ich diesbezüglich bei der Übernahme eines vorhanden Benutzers beachten?

Danke vorab!

[RolandG]

Und gerade ist mir noch ein Fehler aufgefallen: Wenn ich unter "Archive" auf "Älteres..." klicke, erscheint die Übersicht über Jahre, Monate und die Anzahl der jeweiligen Einträge. Wenn ich dort auf einen Eintrag klicke, erscheint immer wieder dieselbe Seite: die Startseite des Blogs mit dem neuesten Eintrag. Allerdings: Die in der Browser-Adressenzeile angezeigte URL deutet auf ein Archiv hin (zum Beispiel ...index.php?/archives/2012/06/summary.html). Was kann ich tun, damit die richtige Seite angezeigt wird?

Danke vorab!

[Timbalu]

Es ist schwer so ins Blaue hinein zur raten... du müsstest wesentlich genauer erklären was du wann und wie gemacht (zB mit "halb automatisierten / halb manuellen Übernahme") hast. Auch ein paar mehr Daten zu deiner Installation könnten helfen.

Du hattest wahrscheinlich mehrere Probleme:
1. Alte Datenbank von MySQL4 auf MySQL5 migrieren
2. Wahrscheinlich auch eine alte Serendipity Version
3. Eventuelles gewolltes Umstellen auf UTF-8

Bevor man nun alles zusammenwurschtelt, sollte man die Punkte der Reihe nach abarbeiten.
Zuerst die Datenbank Migration auf Mysql 5.
Erst wenn das mit dem alten Blog ALLES wieder richtig läuft, kann man daran gehen Serendipity upzudaten. Je nach Startversion kann das gut gehen oder auch vereinzelte Fehler verursachen. Eine davon ist eventuell das missing hashtype field, oder eventuell die fehlende Umwandlung des alten password hashes von MD5.

An welcher Stelle du nun stehst, erschließt sich mir aus dem Bisherigen nicht. Hast du ein neues Blog mit neuem User angelegt und später einzelne Tabelleninhalte übernommen? Oder arbeitest du jetzt mit einem neuen Serendipity und den alten Datenbanktabellen unter MySQL5?
An dieser Stelle wird deutlich, dass es sich eventuell um fehlende Upgrades (der upgrade tasks) handeln kann. Aber auch das ist nur Vermutung.

[RolandG]

@ timbalu: Die alte Datenbank unter MySQL 4.0 war schon auf UTF-8.

Nach Korrektur von "TYPE=MyISAM" durch "ENGINE=MyISAM" und "last timestamp (14) NOT NULL," durch "last timestamp NOT NULL," im Dump ließ sie sich der Dump problemlos in MySQL 5.6 importieren.

An dieser Stelle wollte ich zwar das alte Serendipity in der neuen Umgebung zum Laufen bringen, doch das klappte nicht, weil das alte Serendipity offensichtlich Schwierigkeiten mit der aktuellen PHP-Version hat (oder umgekehrt).

Ich hab das dann nicht weiter verfolgt, weil du ja auch geraten hast, die Daten in eine neue Serendipity-Installation zu übernehmen. Deshalb habe ich Serendipity frisch installiert und einen Benutzer sowie ein paar Beiträge angelegt. Die daraus resultierende Datenbank habe ich exportiert.

Als nächstes habe ich die beiden Dumps miteinader verglichen und die CREATE TABLE-Zeilen des alten Dumps an die des neuen angeglichen - und bin davon ausgegangen, dass der alte Dump nun genau so gut in die Datenbank importiert werden kann wie der neue. Das meinte ich mit halb automatisiert und halb manuell.

Im Prinzip hat das ja auch geklappt - bis darauf, dass ich nun die beiden oben beschriebenen Fehler habe.

Bei dem alten Benutzer ist der hashtype-Wert in der Tabelle 0 bei neu angelegten 1. Der alte Benutzer wäre auch kein Problem, da ich ihn einfach neu anlegen könnte.

[Timbalu]

Es gibt dabei zwei Sachen die ich noch nicht klar habe.
- Warum willst du (im Backend oder als Dump) einen neuen alten Benutzer anlegen, wenn du schon einen neuen mit den korrekten Einstellungen beim Install der neuen Version angelegt hast? Der key des Users (wahrscheinlich 1) wird als authorid für vieles andere in Kreuzverbindungen gebraucht. (Diese Fehler deuten ein wenig darauf hin.)
- Und welche alten Tabelleninhalte hast du von welchen Tabellen in das neue Tabellengerüst übernommen?

Ich hatte aber nur eventuell geraten die Daten in eine neue Serendipity-Installation zu überführen, wenn du sie für künftige Zwecke in UTF8 umwandeln wolltest. Das scheint ja gar nicht der Fall gewesen zu sein.

Eventuell fehlen dir nur ein paar upgrade tasks.
Man könnte versuchen die Serendipity Version in der serendipitty_config_local.inc.php auf die alte Versionsnummer zurückzusetzen, was den Upgrader neu auslöst. Dann müssten die Tasks auf auto YES submitted werden (Ohne Gewähr), da du ja nichts Altes (außer Inhalte) hast... Vielleicht hilft das.

Das mit dem Archiv kann mehrere Ursachen haben (im template selbst, oder falsche authorid Verknüpfungen, oder sonstwelche Dinge wie htaccess Einstellungen, Pfade, oder soetwas).

[RolandG]

@ timbalu: Das mit den Benutzern ist so: Ich habe im alten Blog einen Benutzer, den ich in den neuen gerne übernehmen würde (der ist nicht identisch mit mir - ich selbst habe mich bei der Neuinstallation als Administrator angelegt). Es ist aber kein Problem, diesen Benutzer, den ich ja schon übernommen habe, zu löschen und neu anzulegen. Die alten Tabellen habe ich komplett in das neue System übernommen.

Die Sache mit den älteren Archiven konnte ich gerade lösen: Da war bei der Pfadangabe unter "Konfiguration" -> "Pfade" -> "Relativer HTTP-Pfad" an einer Stelle statt eines einfachen / zwei (also //). Dadurch wurde das Ziel nicht gefunden und die Startseite angezeigt.

Jetzt werde ich mich an der Sache mit den Upgrade Tasks versuchen. Danke für die Tipps!