Upgrade MySQl 4.0.26 auf MySQL 5.x

**uses MSD regulary** Joined: 25 Feb 2009 Posts: 20

Hallo,

"ich möchte auf meinem Server von MySQL 4.0.26 auf MySQL 5.0 upgraden und habe die vergangenen Tage viel dazu gelesen, wobei die Informationsfüll e teilweise erdrückend ist. Auch hier im Forum habe ich die FAQ-Umlaut-Beiträge gelesen.

hier ist bspw. zu lesen:

"Praxishilfe:
Dem aufmerksamen Leser wird nun aufgefallen sein, dass die Wiederherstellung nur dann korrekt funktioniert wenn das Backup in der Kodierung vorliegt, die der neue Server erwartet. Aber woher weiß man, was der Standardzeichensatz eines MySQL-Servers ist?

Dazu gibt uns MySQLDumper glücklicherweise umfassend Auskunft!
Unter Home/MySQL-Variablen/Variablen finden wir eine ganze Reihe von MySQL-Einstellungen:

z.B.:
character_set_client und character_set_connection"

Aber beide vorstehend genannten Variablen tauchen bei mir gar nicht auf, sondern nur chacter_set und character_sets.

Wie erklärt sich das? Vielleicht durch fehlende Einträge in der my.cnf?

Folgende Fragen:

1)
Macht es Sinn, dass ich mit Hilfe von MySQL-Dumper die Daten der 4.0.26 DB sichere und in die 5.x exportiere?

Im www wird nämlich öfters darauf hingewiesen, man solle von einer DB 4.0.x erst in eine 4.1 und dann von dieser wiederum auf die 5.x einspielen.

2)
Wann kommt das Programm DSB's Umlaut Korrektur (DUK) ins Spiel?

Ich frage, weil ich nach dem, was ich gelesen habe, davon ausgehen muss, dass bereits MySQL-Dumper recht viele "Bemühungen" unternimmt, das Ganze richtig zu handeln.

3)
Ich habe auch Hinweise gelesen, dass man - um sich Ärger zu ersparen - einfach auch bei MySQL 5.x latin-1 einsetzen sollte.

Wie seht Ihr das?

Nette Grüsse und herzlichen Dank im voraus
MD-testit

Posted: 2009-02-25, 19:19 Re: Upgrade MySQl 4.0.26 auf MySQL 5.x

Hallo,

schön, dass Du einer der wenigen bist, die sich vorab informieren. Smile

**uses MSD regulary** Joined: 25 Feb 2009 Posts: 20

Hi,

ich danke dir herzlich für die raschen Antworten!

Es wird übrigens bei mir unter MySQL 4.0.26 character_set latin1 angezeigt.

Nach wie vor stellt sich mir die Frage, ob es Sinn macht, nun auch rigoros auf UTF-8 umzustellen? Wenn ich das richtig sehe, müssen das doch auch die PHP-Anwendungen unterstützen, oder nicht?

Ich habe bspw. ein pphBB2 mit diversen MODs und frage mich, ob es da bereits wg. UTF-8 Schwierigkeiten geben könnte?

Nette Grüße
MD-testit

Posted: 2009-02-25, 22:44 (No subject)

Vorsicht: Du wirfst die Funktionalität von Software, die Standardkodierung der Datenbanktabellen und die Kodierung einer Backupdatei an sich durcheinander, so wie es viele tun, da es bisher so wenig fundierte Quellen diesbezüglich gibt.
Seit Version 1.22 und der Veröffentlichung dieses Artikels kämpfe ich gegen all die Halbwahrheiten an. Allerdings fühle ich mich wie Don_Quijote im Kampf gegen Windmühlen. Wink

Der Anteil derjenigen, die den Zusammenhang verstehen und derer, die einfach wild rumprobieren und durch zeitraubende, nächtliche Aktion per Zufallstreffer zum Ziel kommen, beträgt geschätzte 5% zu 95%.

Klartext:
In einer Backupdatei, die in utf8 kodiert vorliegt, können Datenbank-Tabellen gesichert sein, die jeweils andere Kodierungen besitzen können.
Sonst müsste man ja für jede abweichende Tabelle ein eigenes Backup machen.
Es kann auch sein, dass nur Datenbanken enthalten sind, die als Standard-Charset latin1 haben. Dennoch kann die Backupdatei selbst in utf8 kodiert werden und das Einspielen funktioniert wenn MySQL zum Zeitpunkt der Datenübertragung weiß, dass die Befehle zum Anlegen und Füllen von Tabellen in utf8 geliefert werden.

Das Liefern der Befehle in einer bestimmten Kodierung hat nichts mit deren Inhalt zu tun (also dem, was als Text in der Backupdatei drin steht). Den Leuten, die regelmäßig in anderen Foren empfehlen, in den Backups die Stellen "default charset=xxx" zu ändern, könnte ich regelmäßig die Finger abhacken, da das überhaupt nichts mit dem Problem zu tun hat. Es gibt zwar Fälle, wo die Kombination aus falscher Kodierung der Backupdatei und zusätzlicher Anpassung dieser Angabe getreu dem Motto "minus mal minus gibt plus" das Gesamtpaket in Summe wieder zurecht rückt, aber die Darstellung der "Lösung" ist nahezu immer falsch und vermittelt eine technisch verkehrte Orientierung. Die Tippgeber denken, dass wäre die richtige Lösung, da es bei Ihnen funktioniert hat, aber liest man das als Neuling, wird man nie hinter die tatsächlichen, technischen Zusammenhänge kommen.

hoffentlich verständliches Beispiel:
wenn Du MySQL sagst, dass Du Englisch sprichst und die Befehle auf Englisch durchgibst, dann musst Du sogar auf Englisch sagen, dass die nächste Datenbanktabelle als Standardkodierung Deutsch bekommen soll. Du sagst es eben nur auf Englisch und der MySQL-Server versteht das, da er eingangs geantwortet hat, dass er Englisch versteht und ab da davon ausgeht, dass Du Befehle auf Englisch lieferst.
Wenn Du jetzt plötzlich Deutsch quatschst, versteht MySQL mit Sicherheit etwas falsch. Prinzipiell kann MySQL zwar Deutsch, aber anfangs hast Du ja gesagt, dass Du mit dem Server Englisch reden wirst. Also wird der MySQL-Server an den Stellen, wo Deutsche Worte auftauchen Fragezeichen einsetzen, da er sie im enlischsprachigen Raum nicht kennt.

Es kommt also auf die Einigung auf eine "Sprache" (Kodierung) an und hat überhaupt gar nichts mit dem Inhalt zu tun.
Alles klar?