Das war ein Schritt, den wir gehen mussten. Die Entscheidung fiel uns ziemlich schwer, obwohl wir wussten, dass es uns früher oder später Probleme bereiten würde, wie es dann auch geschah.
Vor ein paar Wochen hat uns an einem ganz normalen Tag ein alltäglicher Prozess des Lagerverwaltungsprogramms die Website lahmgelegt. Es war nichts übermäßig Ernstes, denn 20 Sekunden später lief die Website wieder problemlos, aber es war der Tropfen, der das Fass zum Überlaufen brachte und uns dazu bewegte, die Engine der MySQL-Tabellen zu ändern.
Das Problem war, dass die in osCommerce standardmäßig verwendete Engine, MyISAM, bei Leseabfragen deutlich schneller ist, dafür aber eine Tabelle für die Dauer einer Abfrage sperrt, und wenn es sich um eine riesige Tabelle handelt, bei der 135 Abfragen in der Warteschlange auf den Zugriff auf genau diese Tabelle warten, haben wir ein Problem und die Website blockiert als Folge. Sobald die „blockierende“ Abfrage beendet ist, kehrt alles zur Normalität zurück, aber… bis wann? Und schlimmer noch: was, wenn wir nicht da sind, um es zu merken?
Also beschlossen wir, kurzen Prozess zu machen, und stellten auf Empfehlung des Verantwortlichen für unsere Server auf InnoDB um. Dafür bereiteten wir eine Reihe von Tests und Prüfungen vor, die wir vor und nach dem Engine-Wechsel auf unseren lokalen Servern und anschließend in der Vorproduktion durchführten. Obwohl bei den Joins zwischen Tabellen ein Risiko bestand, war deren enorme Menge in unserem Code zu groß, um sie einzeln im Detail zu analysieren. Deshalb entschieden wir uns für diese durchaus recht vollständige Testreihe.
Nachdem wir in der Vorproduktion überprüft hatten, dass alles wie erwartet lief, saßen wir mit der Tastatur in der Hand und den Augen fest auf dem Bildschirm um 5:00 Uhr morgens — wenn kaum Besucher unterwegs sind —, nahmen unseren Mut zusammen und begannen mit dem Backup der Datenbank und direkt danach mit dem Wechsel der Tabellen-Engine. Zuerst die schwersten Tabellen einzeln und danach die leichteren in Gruppen, um die Performance für jene wenigen Mutigen nicht zu beeinträchtigen, die uns zu solch unchristlichen Zeiten besuchten. In etwas mehr als anderthalb Stunden hatten wir bereits alles umgestellt und die Testreihe durchlaufen. Keine Fehler, keine Probleme, nichts Seltsames. Seltsam, oder? Stimmt aber: Diesmal war Murphy auf unserer Seite.
Die Ergebnisse, die wir erhalten haben, sind die erwarteten: keine Tabellensperren mehr, um den Preis einer etwas schlechteren Performance in 10 % der Fälle. Das hoffen wir bald zu lösen, indem wir die zwei oder drei mastodontischen Tabellen, die wir haben, in Teile aufteilen. In ein paar Tagen — oder Wochen — erzähle ich euch auch, wie diese Aufteilung gelaufen ist. Ich empfehle euch, es dann zu lesen; bis dahin lasse ich euch ein paar Links da, falls jemand tiefer in das Thema einsteigen möchte:
- http://www.arsys.info/programacion/myisam-o-innodb-elige-tu-motor-de-almacenamiento-mysql/
- http://dev.mysql.com/doc/refman/5.0/es/converting-tables-to-innodb.html
- http://stackoverflow.com/questions/7335515/migrating-from-myisam-to-innodb
Schreibe einen Kommentar