Bricki serwera - temat zbiorczy

[urban92]

Temat zbiorczy w których będziemy powiadamiali o wszelkich przerwach w działaniu Techvortalu.

Proszę administratorów o wpisywanie w tym wątku okresów przerw, przyczyny konserwacji oraz jej przebiegu i pokrótce skutkach. W razie jakiegoś bricka pozwoli to szybciej zdiagnozować wszelakie usterki. // Onset.

[BBB]

Domniemam, że chodzi o te zaplanowane bricki?

[winuser]

Coś tu się chyba pokrywa - http://techvortal.pl/topic3258.html

[Onset]

Fakt, wątek ten powinien być jednak zablokowany, przylepiony i w ogóle.
Ogłoszenie parafialne numero uno then:
W nocy z soboty na niedzielę planowałem przeprowadzenie konserwacji od godziny 0:00 do 7:00, by wyeliminować często pojawiający się problem z bazą danych. Po wstępnej analizie logów zobaczyłem, że wszystkie problemy powodowała jedna tabela w bazie plików Wordpressa, w której uszkodzone były indeksy. Całość rozpoczęła się z godzinnym opóźnieniem. Wgrałem nowe configi do Percony, specjalnie zoptymalizowane pod kątem naszego serwera wirtualnego, bo oprócz tego cache pochłaniało gigabajty zasobów. Niestety omyłkowo razem z cache wywaliłem plik ze strukturą tabel działających na InnoDB. Urban przywrócił backupa piątkowego wczoraj około godziny 14:30 i jak na razie działa, a całość sprawia wrażenie jakby działała nieco szybciej.
Na czwartek/piątek planuję przerwę techniczną związaną z białą stroną. Nie mam bladego pojęcia ile będzie mogła trwać, dodam więcej info o tej przerwie niebawem.

[urban92]

W związku z koniecznością przeprowadzenia prac modernizacyjnych w nocy z 17 na 18 listopada w godzinach 23:00 do 6:00 możliwe będą przerwy w dostępie do świadczonych usług.

Zespół Śląsk DATA CENTER

[urban92]

W związku z koniecznością przeprowadzenia prac modernizacyjnych w infrastrukturze sieciowej w nocy z 25 na 26 listopada w godzinach 23:00 do 6:00 możliwe będą przerwy w dostępie do świadczonych usług.

--

Due to maintenance works that will take place at night 25-26 November from 23:00 to 6:00 local time (UTC + 1) there will be a possible downtime for the offered services.

[Onset]

Włączyłem na serwerze techvortalu kompresję gzip. Powinno nieco przyspieszyć na platformach mobilnych.



Zarządzam przerwę techniczną na przełomie dni 31 grudnia / 1 stycznia, będę próbował łatać problem z blank screenem wyskakującym sporadycznie przy próbach odpowiadania na posty.

[Onset]

Rozpoczynam pracę z małym poślizgiem nad error 500 przy odpowiedziach. Forum może przez to mieć krótkie przerwy w działaniu.

O zakończeniu prac poinformuję następną wiadomością.

[Onset]

Przetestowano:
- użycie szybkiej odpowiedzi,
- użycie pełnej odpowiedzi,
- szybkiej odpowiedzi z wykorzystaniem linku do ostatniej odpowiedzi,
- pełnej odpowiedzi z wykorzystaniem linku do ostatniej odpowiedzi.

Testujcie przez dobę, jeśli problem nie będzie występował to uznaję problem za rozwiązany.

[Onset]

Update do 3.1.9

[Onset]

Problem od dnia wczorajszego nie wystąpił, zatem uznaję to za resolved.

[Onset]

Dzisiaj w godzinach nocnych (0:00-4:00) będę poczyniał prace konserwacyjne na serwerze - to może skutkować chwilowymi brickami w dostępności forum. Zatem jeśli nastąpią Wam jakiekolwiek problemy z dostępem to o tym wiem.

[Onset]

Done. Puściłem optimize na wszystkich bazach trzymanych u nas na serwerze + rutynowa aktualizacja distro.

[urban92]

Jak zapewne niektórzy z was zauważyli, był brick, już naprawiony.

[Onset]

Taa, problem był podejrzewam spowodowany przez awarię serwera w SLDC, na której stał nasz VPS.

Wyłączenie spowodowało dataloss.

Przez awaryjne wyłączenie, logi transakcyjne były wybrakowane. Generalnie daemon mysql próbował robić rollbacka na pozycji w logu, która nie istniała (w wyniku wyłączenia awaryjnego dane zostały utracone)
W poniższym wpisie widzimy, że linijek wczytanych z loga jest 1108141056, a checkpoint z którego miał być robiony rollback jest ustawiony na 1108141186:

Kod: Zaznacz cały

[ERROR] InnoDB: We scanned the log up to 1108141056. A checkpoint was at 1108141186 and the maximum LSN on a database page was 0. It is possible that the database is now corrupt!

Takie info są niestety na sztywno wpisane (ibdata0, ibdata1), zatem zmiana byłaby upierdliwa.


Daemon ruszał bezproblemowo po ustawieniu parametru innodb_force_recovery=3 (pomijanie rollbacków transakcji).
Problemem jednak był fakt, że nie dało się go zamknąć - daemon oczekiwał na zakończenie transakcji cały czas.
Polecenie kill -9 <pid> powodowało, że owszem - proces znikał, jednakże w jego miejsce pojawiały się następne, co summa summarum wieszało nasz serwer w chwili, gdy go restartowałem. xD

Odwinąłem backup z 24.11.2016 roku i wszystko śmiga.

Kroki które poczyniłem w celu rozwiązania usterki:

1. Backup katalogu /var/lib/mysql,
2. Stworzyłem nowy katalog, który jest teraz głównym katalogiem mysqla. Skopiowałem ze starego katalogu bazę główną mysqla (do tego chown, odpowiedni chmod) i puściłem mysql_upgrade (zauważyłem, że performance.schema dostała porażenia mózgowego) - nie chciało mi się bawić w tworzenie userów od nowa, a w niej wszystkie informacje były zawarte.
Po drodze też odbudowałem tabele:

Kod: Zaznacz cały

+----------------------+
| table_name           |
+----------------------+
| innodb_index_stats   |
| innodb_table_stats   |
| slave_master_info    |
| slave_relay_log_info |
| slave_worker_info    |
+----------------------+

3. Zrestartowałem daemona,
4. Odwinąłem backupy forum i bloga,
5. Póki co wszystko bangla.

Cóż, zaczynam coraz mocniej zastanawiać się nad zmianą providera, SLDC z czego zauważyłem ma dość mierne SLA.

Poza tym, parawirtualizacja ssie. Cholernie ogranicza nam pole manewru.