awaria tabeli mysql i jej skutki

Dziś kolejny zapis moich bojów z linuxem i drupalem.

Zaczęło się niewinnie - zaraz po tym jak pojechałem na wakacje dostałem sms od kumpla (co-admina basoofki), że coś nawaliło. Szybki reset serwera (rękoma administratorów serwerowni) i niby działa, ale coś powoli. Po paru godzinach znowu zdycha, po czym przez dwa dni nie może się zdecydować :).

Wracam z urlopu (2 tygodnie później) i zastaję rozłożoną basoofkę (i wszystkie inne strony www jakie tu są - ten blog, webware, elimu z blogiem...), i serwer z loadem około 80 :). No to czeka mnie diagnostyka.

Na załączonych obrazkach widać wyraźnie pierwszy pik, po którym był restart serwera, dwa dni spokoju i potem już ostre przeciążenie trwające ponad tydzień - wtedy nikt się serwerkiem nie opiekował a strony otwierały się po kilka minut lub wcale.

Pierwszy dziwny objaw na który zwróciłem uwagę - rosnąca zajętość dysku. Na załączonym wykresie widać jak znienacka się to zaczęło i jaki niebezpieczny trend się pojawił - jeszcze kilka dni i dysk by się zapełnił skutecznie 'czymś'. Postanowiłem pójść tym tropem.

No tak, jak jednak odszukać w linuxie co w folderkach się dzieje i gdzie kryje się źródło 'puchnięcia'? Szczególnie jak się na linuxie średnio zna?

Kilka gugli później miałem jakiś trop:

root@sd124:/# du /* -sh

4.1M /bin
15M /boot
[...]
4.0K /srv
0 /sys
16K /tmp
434M /usr
30G /var
0 /vmlinuz

co zatem kryje się w podejrzanie dużym katalogu /var ?

root@sd124:/var# du /var/* -sh

2.5M /var/backups
282M /var/cache
24G /var/lib
4.0K /var/local
8.0K /var/lock
5.1G /var/log
902M /var/mail
4.0K /var/opt
88K /var/run
52K /var/spool
4.0K /var/tmp
5.3M /var/www

jak widać podejrzanie sporo mają /var/lib i /var/log

ponieważ w logach wiadomo co znajdę (tzn będzie tam 'pochodna' jakiegoś błędu a nie samo źródło), zaczynam od /var/lib, schodząc coraz głębiej,

po nitce do kłębka dotarłem do mocno 'spuchniętego' miejsca:

root@sd124:/var# du /var/lib/mysql/testbasoofka/* -sh | grep G
2.0G /var/lib/mysql/testbasoofka/cache_form.MYD
4.0K /var/lib/mysql/testbasoofka/users.TRG
21G /var/lib/mysql/testbasoofka/watchdog.MYD

po chwili obserwacji widzę, że tabela watchdog w bazie testbasoofka przybiera po kilkadziesiąt wierszy co chwilę, zaglądam więc do niej - komunikaty (widoczne też z poziomu interfejsu drupala) informują o uszkodzonej tabeli cache... faktycznie, w phpmyadminie tabela ta ma przy liczbie wierszy ~0 i nie ma typu (innoDB, myIsam) tylko jest opisana jako 'perspektywa'.

Standardowa opcja 'napraw tabele' i...

... spokój... od pół godziny zero błędów i wszystko śmiga... jak miło :)

Życzyłbym sobie, aby każdy problem okazywał się tak prosty do rozwiązania. Co prawda nie bardzo wiem co spowodowało uszkodzenie tabeli cache, ale o ile pamiętam to pierwszy taki przypadek jaki mi się przytrafił, więc następny będzie za jakieś 10 lat :).

Przypadek pokazuje, jak z pozowru niewinna tabelka może spowodować pad serwera. Najwyraźniej jest ona bardzo mocno wykorzystywana przy każdym żądaniu wyświetlenia strony i stąd taka masa błędów, rosnąca w nieskończoność ilość wątków mysql i load. Tabela watchdog (drupalowy dziennik zdarzeń) miała w momencie jej wyczyszczenia prawie milion rekordów :).

Podgląd	Załącznik	Rozmiar
	20090909localhost.localdomain-df-month.png	18.78 KB
	20090909localhost.localdomain-load-month.png	21.91 KB
	20090909localhost.localdomain-memory-month.png	42.8 KB
	20090909_localhost.localdomain-mysql_threads-month.png	21.78 KB