Bernds Blog

Gestern haben wir bei schokokeks.org die MySQL-Server auf die aktuelle Version 5.5 aktualisiert. Der Regelbetrieb war schnell wieder hergestellt, doch heute früh entdeckte ich eine unscheinbare Fehlermeldung im Backup:

ERROR 1457 (HY000): Routine [...] konnte nicht geladen werden. Die Tabelle mysql.proc fehlt, ist beschädigt, oder enthält fehlerhaften Daten (interner Code: -6)

Eine Stored-Procedure konnte also nicht verarbeitet werden. Die genannte Tabelle mysql.proc existierte aber und sah plausibel aus. In der Tabelle war auch die gesuchte Routine enthalten.

Die Lösung war, dass ein recht komplexes SQL-Statement in dieser Routine in den Augen von MySQL 5.5 ungültig war. Und zwar befanden sich "SQL_NO_CACHE"-Markierungen bei allen SELECT-Statements in diesem Query. Diese Markierungen sollen verhindern dass das Ergebnis dieses SELECT imm Query-Cache abgespeichert wird. Ich hatte die nie selbst definiert, MySQL hat die immer automatisch hinzugefügt.

Nun sind diese Markierungen bei UNION-Queries nur noch beim ersten SELECT erlaubt und bei Subqueries gar nicht mehr. Nachdem ich die Routine mit dieser Änderung neu angelegt hatte, funktionierte der Zugriff darauf wieder.

Schade, dass MySQL hier über eine Sache stolpert, die der Parser einer alten Version selbstständig hinzugefügt hat. Und dass dann nicht wenigstens die Fehlermeldung aussagekräftiger ist ("contains invalid SQL" oder sowas).

Vorweg: Man sollte das eigentlich nicht machen. MySQL 5.0 ist alt und zu Recht nicht mehr in den aktuellen Ubuntu-Repositories.

Ein Kunde setzt allerdings die Warenwirtschaft Sage GS-Office ein und da gibt es leider ein Problem. Auch wenn die WaWi mit MySQL 5.1 funktioniert, so arbeitet die Shop-Anbindung GS-Shop intern noch mit einer völlig veralteten Datenbankanbindung und verlangt unbedingt MySQL 5.0.

Praktischer Weise gibt es in den Repositories der LTS-Vorversion Hardy Heron (Immerhin von 2008!) binärkompatible Pakete. Man muss nur die APT-Zeile
deb http://security.ubuntu.com/ubuntu hardy-security main
einfügen und kann dann mysql-server-5.0 installieren.

Da die Server-Version von Ubuntu LTS 5 Jahre Support beinhaltet, wird der MySQL-5.0-Server folglich bis April 2013 mit Sicherheitsupdates versorgt. Ich bete dafür, dass bis dahin auch die letzte Software gemerkt hat, dass MySQL 5.0 veraltet ist.

Wir haben vor Kurzem ein Upgrade von MySQL 5.0 auf 5.1 vollzogen. Nach dem Update fiel auf, dass beim Zugriff auf einige (wenn nicht alle) Views eine Warnung kommt: View [...] has no creation context

Die Meldung lässt sich am einfachsten dadurch beheben, dass man den View einfach mit sich selbst überschreibt. Da dies bei uns eine größere Menge Views war, habe ich dazu folgendes Stück Code geschrieben.
(Ich nutze dafür unsere SQL-Library, die einfach eine gewisse Abstraktion bereitstellt, z.B. die Zugangsdaten aus einem Configfile lesen, DictCursor initialisieren und db.query() als Wrapper für db.execute() und db.fetchall(). Diese Library sollten wir wohl demnächst mal veröffentlichen. :))

#!/usr/bin/python



import re



from sql import sql

db = sql()



views = db.query("select TABLE_SCHEMA `schema`, TABLE_NAME `name` "+

                 "FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION =''")



for v in views:

  print 'fixing %s.%s\n=========================' % (v['schema'], v['name'])

  vdef = db.query("SHOW CREATE VIEW %s.%s" % (v['schema'], v['name']))

  new = re.sub('CREATE .* VIEW (`?%s`?.)?`?%s`?' % (v['schema'], v['name']), 

               'ALTER VIEW `%s`.`%s`' % (v['schema'], v['name']), vdef[0]['Create View'])

  db.query(new)

Gestern habe ich für die LUG Backnang einen Vortrag "Einführung in MySQL" gehalten.

Slides: PDF | ODP

Ich programmiere zur Zeit (schon lange immer so nebenbei) an meinen Python-Bibliotheken zur Datenbank-Ansteuerung. Nichts allgemeines sondern sehr speziell auf die Zwecke des Keks zugeschnitten.

Die letzten Tage bin ich richtig schön weitergekommen, habe meine Bibliotheken ausgebaut, meine Objekte so weit es geht abstrahiert und auch Schreibzugriff auf die Datenbank damit ermöglicht. Eigentlich hat alles geklappt. Nun wollte ich das Frontend noch schnell darauf umstellen. Eigentlich kein Problem, denn ich muss ja nur die Attribute des Objekts füllen und commit() aufrufen.

Nur war dann beim Speichern der Daten immer nur die Hälfte in der DB. Beim debuggen war alles da, beim Testen aller Klassen war alles da. Nur nach dem Erzeugen der Objekte und vor dem DB-Zugriff muss irgenwas schiefeglaufen sein.

Des Übels Wurzel: Ich habe einen kleinen aber feinen Teil in Pythons Dokumentation übersehen: Klassenvariablen. Eine Klassenvariable (die man in der Klassen-Definition einträgt, anstatt sie mit self.var in einer Methode zu setzen) gilt für alle Objekte der Klasse und ihrer Subklassen gemeinsam. D.h. solange man mit einem Objekt arbeitet gibt es kein Problem. Erst wenn man mehrere Objekte der selben Klasse hat und an einer solchen Variable was ändert, dann passieren merkwürdige Dinge.

Auch wieder was gelernt. ;-)

Neulich hat Hanno bei uns das MediaWiki auf eine neue Version geupdatet. Es war von 1.4.15 auf 1.6.8. Daraufhin war die Datenbasis mysteriös kaputt. Genauer gesagt haben manche Seiten gefehlt, manche waren steinalt und manche noch aktuell.

Zur Sicherheit habe ich dann von neuem die Update-Prozedur nochmal mit einem alten Backup der Datenbank nachgestellt und kam zu exakt demselben Ergebnis.

Nach einiger Zeit an Recherche in den Untiefen der Datenbank von MediaWiki habe ich festegstellt, dass sich einiges am Datenbank-Schema geändert hat. Bisher waren die Tabellen 'old' und 'cur' für die Inhalte zuständig, dort wurden die alten resp. die aktuellste Version jeder Seite aufbewahrt.

Im neuen Schema gibt es jetzt (eigentlich logischer) die Tabellen 'page', 'revision' und 'text', die Informationen zu den Unterschiedlichen Seiten, deren Versionen und den entsprechenden Texten speichern. 'page' verlinkt dabei immer auf die aktuelle Revision einer Seite.

Das Debugging hat nun ergeben, dass der update-Wizzard von MediaWiki aus irgendwelchen unerfindlichen Gründen die Datenbank nicht korrekt konvertiert hat. Es wurden Seiten vergessen oder alte Versionen als aktuell markiert.

Als Lösung habe ich ein Programm geschrieben, das die alte 'cur'-Tabelle ausliest und im neuen Datenbank-Schema eine neue Version jeder Seite mit dem Inhalt aus der alten Tabelle erstellt.

Der Einfachkeit halber konvertiere ich nur Artikel im Namespace 0, also normale Artikel.

Leserfrage: Welche Anwendungsbereiche eignen sich derzeit noch nicht für den Einsatz von MySQL?
Marten Mickos: Alle Bereiche, in denen Sie eine schwerfällige und kompliziert zu konfigurierende Datenbank benötigen, die dazu noch einen Haufen Geld kostet.

Quelle: Interview auf ProLinux.

Seit heute haben wir auf dem keks MySQL 5.0 im Einsatz. Zuerst sah alles gut aus, dann haben wir aber bemerkt, dass Umlaute manchmal (genauer: in manchen Webanwendungen) korrekt (als UTF-8), meistens aber falsch (latin1) codiert geliefert werden.

Nun, der Fehler hat uns nen halben Tag gekostet, aber das Problem ist geflickt (ich will es nicht »gelöst« nennen).

Und zwar war MySQL vorher (vor 5.0) einfach inkonsequent, es hat Daten angenommen und Daten ausgeliefert, allerdings nicht auf den charset geachtet. D.h. wenn man die Daten als latin1 eingespielt hatte und mit latin1 wieder ausgelesen hat, dann hat alles gepasst, wenn nicht, dann halt nicht. Offenbar kann das aktuelle MySQL nun mit verschiedenen charsets korrekt umgehen, allerdings erfordert es dafür zwingend die Angabe des Charset. Und zwar muss man nun nach dem Aufbau der Verbindung erstmal das folgende Kommando absetzen um UTF-8 zu bekommen:
SET NAMES utf8;

phpMyAdmin und MediaWiki scheinen das zu machen, fast alle andere Software nicht.
Als Workaround kann man das da in die [msqld]-Section der my.cnf setzen:
init-connect='SET NAMES utf8'