Monatsarchiv für Januar 2012

MySQL-Fehler für Fortgeschrittene

Freitag, den 27. Januar 2012

Manchmal ist es schon echt zum verzweifeln, wie hart einen Bugs in fremden Produkten treffen können.

Unser Hosting Control Panel unterstützt ja auch MySQL als Backend zur Speicherung der “eigenen” Daten. Der Zugriff auf MySQL erfolgt aus Performancegründen ausschließlich mittels Prepared Statements. Nun hat uns kürzlich ein LiveConfig-Kunde auf ein merkwürdiges Problem aufmerksam gemacht: regelmäßig erschien nach der Durchführung eines MySQL-Backups (via mysqldump) in LiveConfig die Fehlermeldung “Prepared statement needs to be re-prepared”.

Die Suche hiernach führte zum MySQL-Bug #41119. Als Workaround haben wir daher nun eine explizite Fehlerbehandlung nach mysql_stmt_execute() eingeführt, welche mit mysql_stmt_errno() die jeweilige Fehlernummer ausliest und in unserem Fall (Fehlercode 1615) das betroffene Statement explizit neu erzeugt.

Nur leider funktionierte dieser Workaround nicht. Also überhaupt nicht.

Ein ausführliches Debugging und Tracing aller Datenbankzugriffe hat dann ergeben, dass unsere Fehlerbehandlung gar nicht aufgerufen wird. Zusätzliche Debug-Ausgaben bestätigten dann tatsächlich, dass mysql_stmt_errno() immer “0″ zurückliefert! WTF!?!?

Diesmal hat MySQL-Bug #53311 zugeschlagen. Beseitigt ist dieser Fehler seit knapp einem Jahr ab MySQL Connector/C 6.0.3. Dummerweise ist diese Version aber nach wie vor nicht freigegeben (”aktuell” verfügbar ist nur Version 6.0.2).

Letztendlich haben wir hier nun den über 650 MB großen bazaar-Branch von libmysql ausgeckeckt, und müssen uns nun zwangsweise die 6.0.3-Release selbst erzeugen

:roll:

Nachtrag:

Finger weg vom MySQL-Connector/C 6.0.3! Ich glaube zu verstehen, warum diese Version noch nicht freigegeben wurde - da funktioniert die Hälfte nicht mehr… vor allem bei Prepared Statements scheint diese Version besonders merkwürdige Fehler zu haben - so funktioniert selbst ein einfaches UPDATE mit drei bestimmten Parametern (String/Int/String) reproduzierbar nicht mehr; ändert man die Reihenfolge der Parameter (zB. String/String/Int oder Int/String/String) so klappt’s plötzlich wieder. Und der Bug liegt definitiv nicht bei uns - selbst ein eigenes Testprogramm (basierend auf dem Beispiel von MySQL) führt bei einer bestimmten Variablenfolge zu einem “Incorrect arguments to mysqld_stmt_execute”. Ob das mit MySQL-Bug #61225 zu tun hat weiß ich nicht, aber auch dessen Fehlerbeschreibung lässt einen fast erschaudern.

Der Trick zu einem stabilen und aktuellen MySQL-Client führt über die GA-Pakete des Community-Servers. Einfach dort die entsprechenden Bibliotheken und Developer-Pakete zusammensuchen, oder aus dem “Generic”-Paket (.tar.gz) die Verzeichnisse “/lib” und “/include” nehmen. Der Client aus MySQL 5.5.20 spricht ebenfalls Protokollversion 10 (wie auch Client 6.0.x), dürfte daher soweit kompatibel sein. Man muss seinen eigenen Code allerdings neu gegen diese Bibliotheken linken, da es ein paar kleinere ABI-Unterschiede gibt.

Übernahme durch Google

Mittwoch, den 18. Januar 2012

Vorhin habe ich einen 15-seitigen Vertrag unterschrieben und an eine Kollegin weitergegeben, um diesen zur Gegenzeichnung an Google zu senden. Ein anderer Kollege wurde gleich hellhörig und fragte, ob das der Übernahmevertrag von Google ist. :mrgreen:

Leider (noch) nicht - es handelt sich “nur” um einen Vertrag zur Auftragsdatenverarbeitung für Google Analytics…