Kleines Update, maximales Chaos: Im Emerge-System von Gentoo-Linux wurde in der letzten Woche das MySQL-Ebuild-Package upgedatet, und zwar eher unscheinbar von Version 4.1.14 auf 4.1.14-r1.

Erste Hürde: der MySQL-Server wollte nicht mehr starten, das mysqld.err-Logfile verriet als Grund:

InnoDB: Error: log file ./ib_logfile0 is of different size 0 8388608 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
060418 14:38:48 [ERROR] Can't init databases
060418 14:38:48 [ERROR] Aborting

Was das schief lief, kann ich nicht sagen, die Dateien ib_logfile0 und ib_logfile1 im MySQL-datadir zu löschen (bzw. nach /tmp zu verschieben) und MySQL neu zu starten war aber eine Lösung.

Mit im Gepäck hatte die neue Version dann aber eine grundsätzliche Andersbehandlung der Character-Encodings der Tabellen. Speziell wurden offensichtlich alle Tabellen-Daten UTF-8-kodiert ausgeliefert, auch wenn die Tabellen ISO-8859-1-encodet angelegt waren.

Und speziell wurden die Daten in allen WordPress-Installationen auf dem Server, die UTF-8-kodiert in ISO-8859-1-kodierten (oder unspezifiziert kodiert weil alten?) Tabellen lagen, nochmals quasi von ISO-8859-1 nach UTF-8 umgewandelt, was dann zerschossene Umlaute im Weblog zur Folge hatte.

Abhilfe schaffte hier nur ein Reimport aller Datenbank-Daten:

1. Dump der Daten, wobei das default-character-set, dem in der Datenbank verwendeten Charset anzupassen ist (latin1 oder latin1) z.B.:

   mysqldump -u root -p --extended-insert=false --default-character-set=latin1 datenbankname > ~/datenbankname.sql

2. Das Dump-File in einem Texteditor mit dem ensprechenden Encoding öffnen und als UTF-8 abspeichern.
3. Im Dump-File zuerst alles Collations mit Suchen und Ersetzen von z.B. latin1_german1_ci auf latin1_general_ci umstellen, und dann alle Charset von latin1 auf latin1 umstellen.
4. Die Daten Reimportieren:

   mysql -u root -p datenbankname < ~/datenbankname.sql

Danach sind dann alle MySQL-Tabellen intern und auch alle Daten auf UTF-8, und die Darstellung wieder korrekt. Und hoffentlich bleibt man von zukünftigem Chaos dieser Art verschont. Keine Problem hatten übrigens meine Gallery– und ein Testwiki auf dem Server, da hier die Tabellen von den jeweiligen Webapplikationen schon explitzit in UTF-8 angelegt worden waren, hier sollte WordPress vielleicht mal nachziehen, wenn die als Default-Charset schon UTF-8 benutzen.

Besonders ärgerlich: Insgesamt ist es aber schon der zweite größere Ausfall wegen eines Datenbank-Updates, der unerwartet einige Nerven gekostet hat. Kann man da nicht mal vorher gewarnt werden?