"A u nas działa", niekończąca się historia
15 Czerwiec 2007
Z niekończących się przygód, jakie prawie codziennie serwuje mi mój provider dzisiaj doszła kolejna niespodzianka: baza danych. WordPress, który niepodzielnie króluje na moim blogu korzysta z MySQL (w wersji 4) na serwerach backendowych. I oto dzisiaj ten serwer postanowił odmówić współpracy …
Zaczęło się od niewinnego „User ‘***’ has exceeded the ‘max_questions’ resource (current value: 70000)”. 70k zapytań to przy nawet 50 zapytań w czasie jednego otwarcia strony WP (wliczam tekst, linki, tagi) daje 1400 wejść bez wyświetlenia tego błędu na godzinę. Zrobiłem więc test – zdjąłem główny plik index.php i nadpisałem go „przerwą techniczną”. Zaczekałem godzinę nie dotykając bazy. W tym czasie plik, który poprzednio serwował strony WordPressowe zamieniłem na _index.php. Po ponad godzinie sprawdziłem ponownie – 70k limit – ten sam błąd. Poprosiłem pomoc techniczną Servage by coś z tym zrobili, bo ewidentnie coś śmierdzi. Sprawdzili i odpisali, że „u nas działa”. U mnie też, czasami, pierwsze otwarcie – OK, następne już błędy. Kolejne: WordPress database error: [MySQL server has gone away]. Gone? Fuck where?
Po kilku przepychankach słownych i wymianie korespondencji poszli po rozum do głowy i zaproponowali, bym utworzył nową bazę, wyeksportował starą, zaimportował do nowej, zmienił ustawienia. Efekt widzicie sami. Wszystko działa OK.
Btw, zostałem przy wersji 4 ze względu na kodowanie. Niby 4-ka eksportowała jako UTF-8, niby wersja 5-ta importowała jako UTF-8, ale jednak widziałem krzaki jako efekt końcowy. Jeśli ktoś zna rozwiązanie, to chętnie poczytam.
Już nie liczę na to, że Servage znów się czegoś nauczy z tej lekcji. Zostałem twardym pesymistą w tej kwestii. Dla mnie jednak, jest to doskonała lekcja, jak klienci nie powinni być obsługiwani i jakich odpowiedzi unikać. Jeśli dyskutuje się z idiotami, w miarę czasu zniża się do ich poziomu …
Mimo, że co najmniej dwa razy dzisiaj i niezliczoną ilość razy wcześniej tłumaczyłem pomocy technicznej firmy Sarvage, że wiem co to cache/proxy/itp i wiem jak omijać efekty stron w pamięci, oni uparcie za każdym razem proszą mnie o sprawdzenie, czy aby przeglądarka nie korzysta z cache.
15 Czerwiec 2007 at 23:55
A już się zastanawiałem czy Cię wrogie słuzby zdjęły z sieci?
Ale powiem Ci, że nie ty jeden masz problem z serwerem. Mój ostatnio padł na 30h!!! Dzwonię po 4h padu do nich, a oni na to, że owszem jest problem i go rozwiązują.
Na pytanie dlaczego nie poinformowali o problemie już odpowiedzi się nie doczekałem – i nie mówię że od razu, ale nawet po 3 dniach… Ehhh… A tak ich polecałem znajomym i sam hostowałem tam w sumie wszystko.
16 Czerwiec 2007 at 07:57
Oprócz kodowania UTF-8 po stronie serwera ważne jest jeszcze kodowanie połączenia z bazą. Ważna sprawa, jakiego narzędzia użyłeś do eksportu (lub np. w jaki sposób WordPress wkłada Ci dane do bazy). Częstym problemem jest, że PHP-owy moduł
mysqldomyślnie łączy się w ISO-8859-1, natomiastmysqlijuż w UTF-8. Wymuszenie połączenia UTF-8 w tym pierwszym uzyskuje się, wykonując zapytanieSET NAMES UTF8;przed innymi, które wykonuje aplikacja.Jeśli to, co opisałem nie jest jeszcze rozwiązaniem Twojego problemu, to może przynajmniej Cię naprowadzi.
16 Czerwiec 2007 at 20:13
O ile pamietam testowalismy z Michalem opcje SET NAMES UTF8, przy okazji innej bazy a efekt byl ten sam – krzak. Ogolnie praca z Unicode jest problematyczna jesli wszystkie elementy po drodze od A do B nie korzystaja z UTF. Problem polega glownie na translacji, ktora – w PHP szczegolnie – jest dosc slabo rozwiazana.
5 Lipiec 2007 at 23:26
Niedawno miałem problemy z kodowanie na styku MySQL – MS SQL. Rozwiązaniem było „set names cp1250″ po stronie MyODBC. Przy okazji strony w PHP która ładowała dane do MySQLa wyszło mi, że MySQL przekodowuje krzaczki samoczynnie. Dlaczego konwersja ze starej na nową nie działa – trudno powiedzieć. Sprawdź jeszcze czy kodowanie na konkretnej bazie danych jest takie samo w starej i nowej bazie, to ważne żeby było to samo. Najlepiej by było gdyby wszędzie po drodze zastosować takie samo kodowanie jak na bazie w MySQL 4, w tym szczególnie na połączeniu z bazą. Alternatywnie spróbuj z MySQLa 4 wyeksportować w ISO8859-2, może wersja 4 nie radzi sobie poprawnie z Unicode…