
Det var et steg vi måtte ta. Det tok oss ganske lang tid å bestemme oss, selv om vi visste at det før eller siden kom til å gi oss problemer, slik det til slutt også gjorde.
For et par uker siden, på en helt vanlig dag, fikk en rutineprosess i lagerstyringsprogrammet nettstedet vårt til å gå ned. Det var ikke spesielt alvorlig, siden nettstedet 20 sekunder senere var oppe igjen og uten problemer, men det var dråpen som fikk begeret til å renne over og som fikk oss til å endre motoren for MySQL-tabellene.
Problemet var at motoren som følger med som standard i osCommerce, MyISAM, er betydelig raskere når den utfører lesespørringer, men til gjengjeld låser den en tabell i den tiden det tar å kjøre en spørring, og hvis det er en gigantisk tabell med 135 spørringer i kø som venter på tilgang til den samme tabellen, har vi et problem, og som følge av det låser nettstedet seg. Når den «blokkerende» spørringen er drept, går alt tilbake til normalen, men… hvor lenge? Og enda verre: hva hvis vi ikke er der for å oppdage det?
Så vi bestemte oss for å skjære gjennom, og etter anbefaling fra personen som har ansvar for serverne våre, gikk vi over til InnoDB. Til det forberedte vi en rekke tester og kontroller som vi kjørte før og etter motorbyttet på de lokale serverne våre og deretter i preproduksjon. Selv om det var risiko knyttet til joins mellom tabeller, var mengden av dem i koden vår så enorm at vi ikke kunne analysere dem én etter én i detalj. Derfor valgte vi å kjøre denne ganske komplette testpakken.
Da vi hadde kontrollert i preproduksjon at alt gikk som forventet, med tastaturet i hånden og øynene klistret til skjermen, klokken 5:00 om morgenen — når det knapt er noen besøkende — tok vi mot til oss og startet med backup av databasen og umiddelbart etterpå med å endre tabellmotoren. Først de tyngste én etter én og deretter de lettere i grupper, for ikke å straffe ytelsen for de få modige som måtte være innom oss på så ugudelige tider. På litt over halvannen time hadde vi allerede endret alt og kjørt testpakken. Ingen feil, ingen problemer, ingenting merkelig. Rart, ikke sant? Men det er sant: denne gangen var Murphy på vår side.
Resultatene vi har fått er som forventet: ingen tabellåser, på bekostning av litt dårligere ytelse i 10% av tilfellene. Det håper vi å løse snart ved å dele de to eller tre mastodontiske tabellene vi har opp i deler. Om noen dager — eller uker — skal jeg også fortelle hvordan den oppdelingen gikk. Jeg oppfordrer dere til å lese det da, men i mellomtiden legger jeg igjen et par lenker for alle som vil gå dypere inn i temaet:
- 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

Legg igjen en kommentar