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.
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.
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.
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.
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…