MySQL 5.0.32 Community

Eigentlich wollte ich das MySQL-Paket von Debian etch verwenden. Dann stiess ich im MySQL Performance Blog auf Bug #15815. Hier die kurze Erklärung von Vadim dazu:

On 4-CPU box 1 thread executes full-table scan select query for 8 sec, but with 4 threads – each thread executes query for 240 sec. It is very strange as threads use only SELECT queries and ideally there should be no any problem in concurrent enviroment, especially for CPU-bound workload.

Behoben ist das ganze in MySQL Enterprise 5.0.30 und in MySQL Community 5.0.33 (source code release) bzw. MySQL Community 5.0.37 (binary release). Ein Work-Around dafür ist:

innodb_thread_concurrency=4 # oder noch niedriger

Sortierschwierigkeiten

Auf der Suche nach einem Paket in dem der obige Bug sowie die aktuellen Sicherheitslücken gefixt ist und auch sonst keine krassen Fehler enthalten sind fand ich Bug #30666 welcher bisher in keinem Community-Release behoben wurde. In den Enterprise-Releases ist er ab 5.0.52 behoben.

It seems that if a query has range conditions on fields of 2 tables or more, the ORDER BY clause is ignored and the rows are returned in unsorted table order.

Das Enterprise-Kunden jedoch nicht immer die besseren Releases kriegen sieht man an Version 5.0.48 (welche zurückgerufen wurde). MySQL konnte dort in noch mehr Fällen nicht mehr korrekt sortieren. Gleich zwei Bugs diesbezüglich gibt es dort:

#30596
The optimization that uses a unique index to remove GROUP BY suffers from the following
flaw: It does not choose the index at the same time as removing GROUP BY, thus it cannot
guarantee ordering the result by the columns in the GROUP BY list.

#31001
MySQL pays no attention to the DESC in the ORDER BY if you order by the primary key and
also include a simple equals where condition on an indexed column.

Hilfe, ich brauche Enterprise!

Der oben beschriebene Sortier-Bug wäre bei der einzusetzenden Anwendung derzeit kein Problem, jedoch enthält die wichtigste Query davon ein IN(). Demnächst wird das Datenbanklayout der Anwendung etwas modifiziert – wie steht zwar noch nicht genau fest – jedoch habe ich keine Lust mich dann evtl. mit diesem Bug rumzuschlagen. Also muss eine Enterprise-Version her. Nach etwas Googlen und studieren der Preisliste (*schwitz*) fand ich einen Mirror der die Enterprise-Sourcen zum Download anbietet. Binaries gibts dort übrigens auch.

Noch mehr Bugs: Replikation

Bei meiner ganzen Sucherei bin ich neben schon beschriebenen Sachen auch auf beunruhigende Tatsachen bezüglich Replikation gestoßen:

#26489
I currently have replication set up between 2 innodb servers (the remote one being very remote) over a VPN on a high latency connection. The relay logs are OFTEN corrupted with odd characters[...].

Ausserdem ist die MySQL-Replikation nicht mehr Absturzsicher. Details dazu kann man im MySQL Performance Blog oder im zugehörigen Bug-Report nachlesen.

Beim Timeout sollte alles weg!

Beim studieren der Changelogs habe ich ausserdem noch folgenden Eintrag gefunden, in meinen Augen total unsinnig. Wenn eine Transaktion abläuft sollte man sie meiner Meinung nach komplett zurückrollen. Oder gibt es Fälle in denen das nicht erwünscht ist bzw. keinen Sinn macht!? Bitte klärt mich auf! Naja richtig konfigurieren kann man es seit 5.0.32 auf Wunsch.

#24200
Starting with MySQL 5.0.13 InnoDB will only roll back the last query on transaction timeouts. In 4.x and up to 5.0.12 it would abort and roll back the complete transaction on timeouts as it still does on transaction deadlocks.