Żeby wybrać jedną z kilku metod cache’owania w IP.Board musimy w pliku conf_global.php określić, którą z metod wybieramy poprzez ustawienie odpowiedniego włącznika.
Żeby skorzystać z memcheche’a należy dodać poniższe parametry, oczywiście w server i port wpisując odpowiednie wartości.
$INFO['use_memcache'] = '1'; $INFO['memcache_server_1'] = '127.0.0.1'; $INFO['memcache_port_1'] = ''11211;
Jednocześnie należy pamiętać, żeby usunąć inne sposoby cache’owania.
Po aktualizacji forum opartego na skrypcie IP.Board do wersji 3.1.2 z wersji 3.0.5 przestało działać kilka rzeczy. Nie wyświetlała się zawartość typu „pokaż czego nie przeczytałem od ostatniej wizyty”, a wyniki wyszukiwania zwracały nic nie mówiące „niczego nie znaleziono”.
Obie rzeczy związane są z aplikacją, którą wykorzystuję do indeksowania treści a jest nią w tym przypadku sphinx.
Okazało się, że w nowej wersji forum (aktualizacja do wersji 3.1.2 z wersji 3.0.5) zmieniła się struktura zapytań do indeksera i wymaga była aktualizacja pliku konfiguracyjnego sphinx.conf
Po jego aktualizacji i przebudowaniu indeksów obie usługi na forum zaczęły działać prawidłowo.
W IP.Board przy podglądzie tematu na samym dole (w domyślnym temacie) znajdują się ikony pozwalające na podzielenie się stroną w różnych mediach. Domyślnie nie ma tam polskich serwisów.
W przygotowanej paczce znajduje się rozszerzenie o niektóre polskie serwisy.
Jest sobie forum postawione na IP.Board, który jest prawie idealny. Prawie, ponieważ używa mysql’a zamiast postgresql’q. Gdyby używał tego ostatniego były perfekcyjny.
Tabela posts używa inno db, o którym im więcej wiem, tym bardziej mam go dość. No ale wracając.
Z cron’a chodzą sobie backupy baz danych, między innymi mysqldump, który od kilku dni (niestety) wywalał się z następującym komunikatem:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `ibf_posts` at row: 111598
mysqldump: Got error: 2002: Can't connect to local MySQL server through socket
Co w logach widziane było tak: (zresztą select count(*) from ibf_posts, skutkowało tym samym błędem)
InnoDB: Page checksum 396689542, prior-to-4.0.14-form checksum 4074025863 stored checksum 4054066906, prior-to-4.0.14-form stored checksum 1768235130
Page may be an index page where index id is 0 6702
Database page corruption on disk or a failed file read of page 400.
You may have to recover from a backup.
It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error.
If the corrupt page is an index page you can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption.
See also InnoDB: about forcing recovery.
Ending processing because of a corrupt database page.
Number of processes running now: 0
restarted
Strona polecana przez logi jest ok, poza tym, że procedura tam opisana do niczego nie prowadzi. Mimo:
InnoDB: !!! innodb_force_recovery is set to 4 !!!
Skończyło się propozycją wysłania stack trace’a, zgodnie zkolejną opisaną procedurą: http://dev.mysql.com/doc/mysql/en/using-stack-trace.html
Mam to w nosie.
A ponieważ cała baza i tak działa (aktualnie backupuje się co godzina katalog /var/lib/mysql i jest spokój.)
W sumie trzeba mi było od razu zastosować się do procedury opisanej na pierwszej polecanej stronie. Czyli skopiować dane, wywalić tabelę, założyć tabelę, przywrócić dane.
W sumie wygląda prosto, ale … nie miałem jak wykonać dumpa, co gorzej większość zapytań korzystających z całych kluczy wywalało się. Całe szczęście dało się wyciągnąć z całej tabeli pole pid, które jest kluczem głównym tej tabeli.
Mając to pole, mogłem wyciągnąć dane po kolei i zapisać je sobie na boczku, potem już łatwo: skasować tabelę, załadować (bez kluczy) wgrać dane i zapiąć klucze.
W czasie pracy powstały następujące pliki:
Które można sobie pobrać tutaj: ip.board.posts.tar.bz2
Na koniec warto wykonać:
OPTIMIZE TABLE ibf_posts;
Z ciekawostek w czasie pracy:
Dla niektórych zapytań pojawiał się następujący błąd: ERROR 1030 (HY000): Got error -1 from storage engine co doprowadziło do przeczytania wątku na stronie mysql’a: http://bugs.mysql.com/bug.php?id=30225 który mnie po prostu rozbawił, jako że nie uznano tego błędu za błąd, a receptą była aktualizacja. Słabo?
IP.Board jest najlepszym jaki do tej pory spotkałem oprogramowaniem do forum. Jest to oprogramowanie płatne, na dodatek w sposób mieszany. Po pierwsze płacimy za zakup licencji $150, a potem co pół roku (jeżeli chcemy mieć dostęp do aktualizacji) $25. Nie są to duże sumy jeżeli utrzymujemy forum nie jest hobbystyczne.
Nadszedł czas aktualizacji, wymuszony niejako przez exploita, który zainfekował stronę. Było trochę problemów z uzyskaniem plików instalacyjnych, bo nie była opłacona licencja (ta odnawialna). Ale po kilkudniowej przygodzie i wymianie kilkunastu maili ze wschodnim wybrzeżem, co jest zadaniem dość niewdzięcznym ze względu na 6 godzin różnicy (u nich jest wcześniej).
Jestem naprawdę pod wrażeniem tego jak zostało napisane narzędzie do aktualizacji. Sama aktualizacja przebiegła następująco:
Po pobraniu plików wgrywamy całość do naszej instalacji i odpalamy admin/upgrade/index.php prawda że maksymalnie proste?
To taka teoria. Praktyka pokazała, że mysql znowu pokazał swoje złe strony. Procedura aktualizacji zakończyła się porażką, ponieważ polskie znaki diakrytyczne … znikły z bazy, wymienione na znaki zapytania. Niemiło. Okazało się że musiałem przestawić ustawienia mysql’a żeby osiągnąć pożądany efekt. Niestety przestawienie ustawień mysql’a spowodowało, że jeden z blogów przestał wyświetlać polskie znaki. Krótka analiza kosztów ujawniła, że łatwiej mi będzie doprowadzić ów blog do porządku, niż walczyć z forum.
Druga próba aktualizacji została zakończona całkowitym sukcesem.
Niestety wieczorne czytanie RSS’a spowodowało, że uśmiałem się setnie. Właśnie została opublikowana wersja 3.0.3, więc jutrzejszy ranek spędzę na kolejnej aktualizacji. Mam nadzieję, że tym razem będzie krótka i bezbolesna.
Dla pamięci ustawienia dodane do mysql’a (/etc/mysql/my.conf)
[mysqld]
character-set-server = utf8
character-set-client = utf8
character-sets-dir = /usr/share/mysql/charsets/
default-character-set = utf8
init_connect='SET collation_connection = utf8_general_ci'
init_connect='SET NAMES utf8'
collation-server = utf8_general_ci
[mysql]
default-character-set = utf8
[client]
default-character-set=utf8
Forum Klubu Miłośników Zegarów i Zegarków zaczynało powoli dostawać zadyszki z którą nie potrafiłem sobie poradzić. Nie pomagała optymalizacja bazy danych, na krótko pomogło przeniesienie serwisu na inny serwer. Obciążenie w szczycie doprowadzało do tego, że serwis raz na tydzień wykładał się z przeciążenia. Wspólnie z założycielem forum doszliśmy do wniosku, że czas zmienić silnik na bardziej wydajny.
Wybór padł na IP.Board i po migracji, zakończyła się przygoda forum ze skryptem phpBB. Sama migracja przysporzyła troszkę kłopotów, ze względu na modyfikacje jakim poddany był wcześniejszy silnik (by przemo).
Koniec końców forum z nowym silnikiem i nowym wyglądem wystartowało.
Oparte na WordPress & Theme by Anders Norén
