Efter mycket om och men är vi tillbaka igen.
Denna gång var det ett betydligt enklare, men otroligt mycket mer svårhittat problem som sänkte forumet.
MySQL hade bara dött med en SIGSEGV i fredags och vägrade efter det att starta. Alla tester visade att databasen var hel, men trots detta var MySQL synnerligen omedgörlig.
Just signal 11, eller SIGSEGV är rena slasktratten när det kommer till felmeddelanden och jag fick göra en stack trace på vad mysql gjorde precis när den kraschade. Backtrace gav att kommandot som var det sista MySQL gjorde innan krasch var: _end
Super, inte mycket att gå på.
Intrång och därmed försök till att byta ut binärer misstänktes och det är inte lätt att försöka hitta spår efter eventuella intrång. OM det hade varit intrång hade vi fått göra en komplett ominstallation och verifiera att ingen skadlig kod tagit sig in någonstans.
Idag verifierades databasen på extern server, så vi visste i alla fall att vad som än hade hänt med servern så skulle vi kunna komma upp igen, dock med längre nertid.
Slutligen tog jag en rövare och körde en kontroll på databasen som innehåller användare och rättigheter, alltså databasen mysql som är synnerligen viktig för mysqls funktion. Det visade sig att det var en liten hicka i de tabellerna och efter att dessa reparerats så var mysql glad igen, och här är vi nu, tillbaka på nätet igen!
Att det blev sån lång nertid för ett, kan man tycka, trivialt fel var att MySQL i detta fall hade en så pass dålig felhantering att man blir lite mörkrädd. Nog sjutton hade man kunnat få _lite_ mer information från databashanteraren att denna vitala del för funktionen inte mådde bra? En så pass generell felkod som kan betyda allt från trasig databas till trasig hårdvara och allt däremellan var inte så vidare snyggt gjort.
Varför hände detta? Troligen på grund av den nertid vi hade ett dygn innan denna krasch. Då tiltade en vital del i hanteraren för de virtuella servrarna som vår leverantör har. Det gjorde att vår server genast gick ner, synnerligen oplanerat och sådant gillas inte av mysql. Ca ett dygn senare klarade den med andra ord inte längre att läsa databasen med viktig intern information och därmed kastade den in handduken.
Vad lär vi av detta? Att det inte räcker med att vara igång och lita på InnoDB, man måste manuellt verifiera att alla delar av databasen och dess hanterare fungerar korrekt!
Vi ber återigen om ursäkt för nertiden och lovar bättring (för varje krasch lär vi oss nått nytt!)
//IT-gruppen genom bollman
Svara med citat
Ursprungligen postat av bollman
