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?