Het was een stap die we moesten zetten. We hadden er behoorlijk wat moeite mee om de knoop door te hakken, ook al wisten we dat het ons vroeg of laat problemen zou opleveren, zoals uiteindelijk ook gebeurde.
Een paar weken geleden haalde op een doodgewone dag een alledaags proces van het magazijnbeheerprogramma onze website onderuit. Het was niet bijzonder ernstig, want 20 seconden later draaide de site weer zonder problemen, maar het was de druppel die de emmer deed overlopen en ons deed besluiten de engine van de MySQL-tabellen te wijzigen.
Het probleem was dat de engine die standaard in osCommerce wordt gebruikt, MyISAM, veel sneller is bij het uitvoeren van leesquery’s, maar daar staat tegenover dat hij een tabel vergrendelt gedurende de tijd die nodig is om een query uit te voeren, en als het om een gigantische tabel gaat met 135 query’s in de wachtrij die toegang tot diezelfde tabel willen krijgen, hebben we een probleem en blokkeert de website als gevolg daarvan. Zodra de “blokkerende” query is beëindigd, wordt alles weer normaal, maar… tot wanneer? En erger nog: wat als we er niet zijn om het op te merken?
Dus besloten we de knoop door te hakken en, op aanbeveling van de verantwoordelijke voor onze servers, over te stappen op InnoDB. Daarvoor maakten we een reeks tests en controles die we vóór en na de enginewijziging uitvoerden op onze lokale servers en daarna in preproductie. Hoewel er risico zat in de joins tussen tabellen, was de enorme hoeveelheid daarvan in onze code te groot om ze één voor één grondig te analyseren. Daarom kozen we ervoor om deze behoorlijk complete testreeks uit te voeren.
Toen we in preproductie hadden gecontroleerd dat alles liep zoals verwacht, zaten we om 5:00 uur ’s ochtends — wanneer er nauwelijks bezoekers zijn — met het toetsenbord in de hand en de ogen aan het scherm gekluisterd, verzamelden moed en begonnen met de databaseback-up en direct daarna met de wijziging van de tabelengine. Eerst de zwaarste één voor één en daarna de lichtere in groepen, zodat we de prestaties niet zouden belasten voor die paar dappere bezoekers die ons op zulke onmogelijke uren een bezoek brachten. In iets meer dan anderhalf uur hadden we alles al gewijzigd en de testreeks uitgevoerd. Geen fouten, geen problemen, niets vreemds. Vreemd, toch? Maar het is echt zo: deze keer stond Murphy aan onze kant.
De resultaten die we hebben behaald zijn de verwachte: geen tabelvergrendelingen meer, ten koste van iets slechtere prestaties in 10% van de gevallen. Dat hopen we binnenkort op te lossen door de twee of drie mastodontische tabellen die we hebben in delen op te splitsen. Over een paar dagen — of weken — vertel ik ook hoe die opsplitsing is gegaan. Ik raad jullie aan dat dan te lezen, maar ondertussen laat ik alvast een paar links achter voor wie zich verder in het onderwerp wil verdiepen:
- 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
Geef een reactie