SQL Error 2002+Problem z VPS

DoreK | 2018-01-17 15:58:54 UTC | #1

Witam, problem z błędem 2002 po kilku restartach z powodu problemów z VPS’em, tak jak pisałem na pogaduchach: wszystko co na vps jest postawione przestało działać mimo iż był włączony, nie dało też się zalogować na ssh itd. Kilka minut po restarcie miałem to samo, więc podejrzewam, że coś się dzieje z węzłem n67, ale w tej sprawie już wysłałem zgłoszenie w panelu.
Wie ktoś jak rozwiązać ten błąd z sql? Serwer MC, forum, sklep nie mają połączenia z bazą a w konsoli takie cuś po wpisaniu mysql

kubus | 2018-01-17 14:02:45 UTC | #2

/etc/init.d/mysqld stop
mysqladmin -u root -p shutdown
pkill -9 mysqld
chmod 777 /var/run/mysqld/mysqld.sock
reboot

DoreK | 2018-01-17 14:05:16 UTC | #3

Zaraz sprawdzę, ale podejrzewam że jednak coś z dyskiem =)

Niemożliwe jest to że mój VPS jest zapełniony, skoro niedawno było poniżej 50% zajęte.
/edit: To może lepiej poczekać na odpowiedź w tickecie, bo boję się że coś jeszcze bardziej spierdzielę :thinking:

DBanaszewski | 2018-01-17 14:07:22 UTC | #4

Wejdź na VPSa i daj zrzut z df -h :)

DoreK | 2018-01-17 14:09:19 UTC | #5

W df-h to w ogóle cuda się dzieją:

Było około 40% - czyżby baza wyparowała?
No ale tutaj widać że df-h pokazuje co innego niż proxmox : V Już miałem taki przypadek i się okazało że dysk na węźle padł :v

DBanaszewski | 2018-01-17 14:11:48 UTC | #6

Te pola typu storage to miejsca, gdzie znajdują się ISO itp.

Sprawdź, czy baza danych działa: mysqladmin -u root -p status

Jeżeli na węźle padłby dysk, to dlaczego uruchomił Ci się VPS? Jak padnie nam HDD czu SSD to włączysz komputer? (No w moim przypadku nie dało się włączyć XD)

DoreK | 2018-01-17 14:13:43 UTC | #7

Też fakt, to w takim razie dlaczego df-h podaje 16% a proxmox 46%?

Co do komendy:

DBanaszewski | 2018-01-17 14:15:13 UTC | #8

Dysk n67 jest zapełniony w 46.4% ;) (a nie Twój VPS)

Z tego co tu pisze to MySQL server działa.

Przykład n65

Mój VPS:

DoreK | 2018-01-17 14:15:51 UTC | #9

Dobra, jestem chyba zbyt wkurzony tą sytuacją i walę takie głupoty że szkoda gadać XDDD
No to działać działa a w pma się nie wbije bo wywala ten sam błąd. Spróbuję komendy od @kubus

DBanaszewski | 2018-01-17 14:17:11 UTC | #10

W pliku /etc/mysql/ zobacz jaki masz socket w sekcji [client].
Prawidłowy: socket=/var/lib/mysql/mysql.sock.
Spróbuj również: sudo chmod -R 755 /var/lib/mysql/ i potem sudo service mysql restart.

DoreK | 2018-01-17 14:24:24 UTC | #11

Jaki plik? Bo /etc/mysql/ zbyt wiele mi nie mówi (albo jestem tak głupi że nie ogarniam )
Po wpisaniu komendy na restart mysql pokazało się to:

Nieznajomy11 | 2018-01-17 14:26:26 UTC | #12

Zajęte miejsce w proxmox to rozmiar pliku dysku guesta na hoście. Kiedy zajmiemy 15 gb a potem usuniemy 5, to te 5 zostanie zapelnione zerami i nadal w proxmox bedziemy widzieli 15 gb uzyte.

https://forum.lvlup.pro/t/proxmox-ve-5-i-zjadanie-dysku/4530

DBanaszewski | 2018-01-17 14:25:40 UTC | #13

sudo systemctl status mysql.service walnij i pokaż :D

DoreK | 2018-01-17 14:27:43 UTC | #14

Tutaj przewinąłem tekst w prawo (strzałką) bo trochę ucięło

Nieznajomy11 | 2018-01-17 14:35:28 UTC | #15

Masz w ogóle folder /var/run/mysqld i /var/lib/mysql?

DoreK | 2018-01-17 14:37:06 UTC | #16

w /var/ jest skrót do folderu /run/ w którym znajduje się pusty folder mysqld
folder var/lib/mysql istnieje i są tam moje bazy oraz inne rzeczy :V

DBanaszewski | 2018-01-17 14:37:25 UTC | #17

Skopiuj to i usuń MySQL server a zainstaluj MariaDB server ;)
Nie wiem czy proces migracji się uda, ale jeżeli tak, to będzie wszystko sprawne :D

DoreK | 2018-01-17 14:38:16 UTC | #18

Wolę w ten sposób nie ryzykować - dane tu mają kilka GB, trochę by mi z tym pewnie zeszło a znając mojego pecha to by się jeszcze bardziej schrzaniło. Chcę zostać przy MySQL :>

Nieznajomy11 | 2018-01-17 14:38:38 UTC | #19

Czy ja wiem. Aby nie próbować na żywca kopiować baz - bo może się któraś nie skopiować.

DBanaszewski | 2018-01-17 14:41:49 UTC | #20

Spróbuj tego: mysqldump -u root -p haslo_roota nazwa_bazy > dumpfilename.sql - jeżeli nie działa, czytaj dalej.

Wykonaj to:

sudo apt-get remove mysql-server
sudo apt-get install mysql-server

Musi być tam REMOVE, a nie PURGE, bo to usunie wszystkie pliki, a tak to tylko aplikację.
Na wszelki wypadek zrób kopię za pomocą cp lub spakuj to w np. tar.gz.

Nieznajomy11 | 2018-01-17 14:43:11 UTC | #21

Ja na początku bym jednak spróbował zabić proces:

kill $(ps aux | grep mysql | awk '{print $2}')

a potem zrestartować vps:

 reboot

DoreK | 2018-01-17 14:46:55 UTC | #22

Nie pomogło, dalej wywala 2002.
@DBanaszewski mam (jak widać na ss wyżej) kilkanaście baz (choć to sys widzę pierwszy raz na oczy, albo mi umknęło albo po prostu to nie jest baza XD) - dla każdej bazy użyć mam tej komendy? w sensie że
mysqldump -u root -p haslo_roota dcraft_wiki > dumpfilename.sql
mysqldump -u root -p haslo_roota dcraft_sklep > dumpfilename.sql
mysqldump -u root -p haslo_roota Forum > dumpfilename.sql
i tak dalej?

DBanaszewski | 2018-01-17 14:47:59 UTC | #23

Yep.

Nieznajomy11 | 2018-01-17 14:52:00 UTC | #24

#!/bin/bash

mkdir -p dumps

for database in $(mysql --defaults-file=/etc/mysql/debian.cnf -B -s -e 'show databases' | grep -v information_schema)
do
    mysqldump --defaults-file=/etc/mysql/debian.cnf --skip-lock-tables $database > "dumps/$database.sql"
done

Powinno od razu wszystkie wyciągnąć. Nie wiem jak to ma się na ubuntu, bo w końcu debian.cnf
Jak coś to po prostu musisz zmienić w komendach –defaults-file na zwykłe logowanie.

kubus | 2018-01-17 14:56:04 UTC | #25

Ehh.
mysqldump –defaults-file=/etc/mysql/debian.cnf –routines –flush-privileges –all-databases > /root/dump.sql

Nieznajomy11 | 2018-01-17 14:56:55 UTC | #26

Pakowanie wszystkiego do jednego pliku jest nieeleganckie :thinking:

kubus | 2018-01-17 14:57:54 UTC | #27

No bywa. Sam z tego korzystam, działać działa, więc nie widze problemu oprócz estetyki.

DoreK | 2018-01-17 14:58:38 UTC | #28

@Nieznajomy11 zrobiłem tak jak doradziłeś i:

czo teraz!

DBanaszewski | 2018-01-17 14:59:11 UTC | #29

Skorzystaj z mojej porady:

[quote=”DBanaszewski, post:20, topic:4994”]
Wykonaj to:

sudo apt-get remove mysql-server
sudo apt-get install mysql-server

Musi być tam REMOVE, a nie PURGE, bo to usunie wszystkie pliki, a tak to tylko aplikację.

[/quote]

DoreK | 2018-01-17 15:06:25 UTC | #30

Ok, zrobiłem kopię za pomocą tar gz:
tar -zcvf /bazaKopia/kopiavarlibmysql.tar.gz /var/lib/mysql/
I do tar.gz poszło wszystko prócz folderów z moimi bazami które mają na pewno ponad 300mb, więc wychodzi na to że muszę dla każdej bazy zrobić inną kopię :thinking:
/edit: Jednak nie, coś tam skopiowało ale wydaje mi się że nie wszystko skoro plik tar.gz ma wagę 162mb :thinking:

SystemZ | 2018-01-17 15:16:40 UTC | #31

Wybaczcie za utrudnienia, wygląda na to że na n67 skrypt do backupów się trochę zapomniał, dodatkowo monitoring nie zwrócił mi na to uwagi a ciężko być na bieżąco z ponad 40 węzłami ręcznie sprawdzając wiele rzeczy przez SSH więc monitoring powinien być tu niezawodny. Jestem w trakcie badania co dokładnie miało miejsce że nie dostałem o tym alertu.

Nie zdążyłem się zapoznać z całym wątkiem ale jeśli wystąpiły problemy z plikami na dysku to sugeruję po prostu przywrócić najświeższy backup.

DBanaszewski | 2018-01-17 15:17:36 UTC | #32

[quote=”SystemZ, post:31, topic:4994”]
przywrócić najświeższy backup
[/quote]

Ciekawe czy @DoreK zalicza się do osób robiących backup, czy do tych którzy “będą” robić backup .

DoreK | 2018-01-17 15:17:59 UTC | #33

Robię backup serwerów MC na vps :facepalm:

kubus | 2018-01-17 15:19:40 UTC | #34

Dodam też, że mam serwer na n67 i były problemy z tym, że serwer się co chwile ścinał i pomagał tylko reboot, no cóż. Zrobiłem reinstalla.

DoreK | 2018-01-17 15:20:28 UTC | #35

Czyli ten sam problem co u mnie - też się ścinał i musiałem stopować w panelu bo nie szło inaczej. Może przez to właśnie mam te problemy z mysql.

kubus | 2018-01-17 15:21:06 UTC | #36

Ech.. myślałem, że coś w konfiguracji popsułem, a to jednak nie ja mam tylko te problemy

SystemZ | 2018-01-17 15:32:35 UTC | #37

Ze wstępnych ustaleń wynika że nastąpiło to dziś około 02:00.

Tak czy inaczej, dodałem dla wszystkich węzłów więcej alertów odnośnie dysków i podniosłem priorytet dla tych alarmów, na przyszłość takie zdarzenia nie powinny mieć miejsca, a nawet jeśli by się zdarzyły to będą występować krócej.

DoreK | 2018-01-17 15:38:56 UTC | #38

Sprawdziłem logi swojego serwera i padł dopiero o 10:39:06 :V
Pytanie: reinstalować mysql czy czekać?

DBanaszewski | 2018-01-17 15:42:27 UTC | #39

To nie jest reinstalacja całego MySQL tylko aplikacji - jeżeli użyjesz opcji purge wtedy to możesz uznać reinstalacją całkowitą, gdyż pliki itp. są usuwane, a przy remove jest usuwana tylko aplikacja.

DoreK | 2018-01-17 15:44:24 UTC | #40

No to o to mi chodzi :thinking:
Wykonałem te komendy (remove a potem install) i dalej jest ten problem XD @DBanaszewski

DBanaszewski | 2018-01-17 15:45:47 UTC | #41

No to wiesz jaka opcja pozostała?

DoreK | 2018-01-17 16:21:59 UTC | #42

Zastanowię się nad tą propozycją jeszcze.
@SystemZ wybacz za moje błędne info, mój serwer MC (i VPS prawdopodobnie też się ściął o tych godzinach) wyłączył się o 03:18:39 dziś i włączyłem go o 10:04:19, po czym znów się wyłączył o 10:39:06. Włączyłem go ponownie ale zauważono problem z bazą danych (wcześniej działała) i wyłączyłem wtedy VPS a potem uruchomiłem ponownie.
co robić, jak żyć?

SystemZ | 2018-01-17 18:29:32 UTC | #43

Po głębszej analizie mogę wyjaśnić co dokładniej miało miejsce.
Jak już wspomniałem we wcześniejszym poście miejsce na dysku hosta uległo wyczerpaniu
https://forum.lvlup.pro/t/sql-error-2002-problem-z-vps/4994/31

W momencie gdy miejsce uległo wyczerpaniu a system operacyjny Twojego VPS próbuje zapisać nowe dane i nie wystarczą mu wcześniej “zadeklarowane” bloki, może nastąpić uszkodzenie danych.
Aby temu zapobiec proces odpowiedzialny za wirtualizację pauzuje VM (wirtualną maszynę) aby poczekać na moment gdy wymagane miejsce będzie dostępne na hoście, wtedy gdy miejsce się zwalnia, po kliknięciu na “start” VM wraca do normy bez problemu z danymi.
Taka pauza jest przezroczysta dla systemu, po wznowieniu system działałby poprawnie, odczuwalne to jest jako “zwieszka” systemu.

Niestety tak się nie stało ze względu na fakt że prawdopodobnie VM zostało wyłączone “na twardo” a następnie włączone, a tak może wystąpić przy użyciu wyłącz/włącz w panelu klienta.
Oznacza to że prawdopodobnie wszystkie otwarte i tylko po części zapisane dane mogły zostać naruszone gdyż potrzebne operacje na plikach nie zostały dokończone.
Sądzę że ochroną od strony VPSa przynajmniej od strony bazy danych byłoby korzystanie z logu binarnego, w tym wypadku po restarcie VPS baza MySQL odtworzyłaby bieg zdarzeń i wycofała niekompletne operacje zostawiają stan trochę “do tyłu” lecz spójny. Nie jestem pewien czy zabezpieczyłoby to w 100% takie wypadki i czy jest to standardowa konfiguracja w dystrybucjach. Obstawiam że należy to włączyć samemu ze względu na większe zużycie miejsca na dysku.

Tak czy inaczej sądzę że sytuacja jest po części z mojej winy i sądzę że warto robić co się da aby klienci byli zadowoleni więc zobowiązuje się do bezpłatnego przywrócenia dostępnej wewnętrznej kopii zapasowej w tym konkretnym przypadku. Szczegóły zostaną ustalone już w systemie ticketów. Dla przejrzystości wspomnę że jest to zgłoszenie numer 17736.

DoreK | 2018-01-17 18:34:43 UTC | #44

Jak się cieszę że doszło do tego w nocy, a nie w środku dnia. Podejrzewam że strata po backupie będzie niewielka. Ciekawe tylko jak ze stratą graczy…
a teraz powiem “a nie mówiłem? :>” (chodzi o to że od początku podejrzewałem problem z dyskiem hehe)

DoreK | 2018-01-18 07:50:22 UTC | #45

Postanowiłem zainstalować MariaDB i baza w teorii działa ale jest błąd np na forum ‘1932 - Table ‘Forum.mybbdvzshoutbox’ doesn’t exist in engine‘ i w pma pokazuje że bazy bazy maja 0B+nie da się w nie wejść.

Aylin | 2018-12-20 23:34:47 UTC | #46