1030 Wystąpił błąd 28 z silnika pamięci masowej

Pracuję nad projektem, w którym muszę utworzyć bazę danych z 300 tabelami dla każdego użytkownika, który chce zobaczyć aplikację demonstracyjną. działało dobrze, ale dzisiaj, gdy testowałem z nowym użytkownikiem, aby zobaczyć wersję demonstracyjną, pokazał mi ten komunikat o błędzie

1030 Got error 28 from storage engine

Po spędzeniu czasu na googlowaniu odkryłem, że jest to błąd związany z przestrzenią bazy danych lub plików tymczasowych. Próbowałem to naprawić, ale mi się nie udało. teraz nie jestem nawet w stanie uruchomić MySQL. Jak mogę to naprawić i chciałbym również zwiększyć rozmiar do maksimum, aby nie napotykać tego samego problemu raz po raz.

Błąd MySQL „ 28 z silnika pamięci ” - oznacza „ za mało miejsca na dysku ”.

Aby wyświetlić miejsce na dysku, użyj polecenia poniżej.

myServer# df -h

Wyniki muszą być takie.

Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/vdisk     13G     13G     46M   100%    /
devfs         1.0k    1.0k      0B   100%    /dev

Aby rozwinąć tę kwestię (chociaż jest to starsze pytanie); Prawdopodobnie nie chodzi o samą przestrzeń MySQL, ale ogólnie o przestrzeń, zakładając, że pliki tmp lub coś takiego. Mój katalog danych mysql nie był pełny, partycja / (root) była

Miałem ten sam problem w AWS RDS. Było to spowodowane tym, że wolne miejsce (miejsce na dysku twardym) było pełne. Musisz zwiększyć przestrzeń lub usunąć niektóre dane.

Mój / tmp wynosił% 100. Po usunięciu wszystkich plików i ponownym uruchomieniu mysql wszystko działało dobrze.

Mój folder / var / log / apache2 miał 35g, a niektóre logi w / var / log łącznie były innymi 5g mojego 40g twardego dysku. Wyczyściłem wszystkie dzienniki * .gz i po upewnieniu się, że inne dzienniki nie zrobią złych rzeczy, jeśli pomieszam je, po prostu je wyczyściłem.

echo "clear" > access.log

itp.

Sprawdź swoją kopię zapasową, aby sprawdzić, czy możesz usunąć starszą niepotrzebną kopię zapasową.

Miałem podobny problem z powodu moich logów binarnych replikacji .

W takim przypadku po prostu utwórz cronjob, aby codziennie uruchamiać to zapytanie:

PURGE BINARY LOGS BEFORE DATE_SUB( NOW(), INTERVAL 2 DAY );

Spowoduje to usunięcie wszystkich dzienników binarnych starszych niż 2 dni.

Znalazłem to rozwiązanie tutaj .

Prosty: $ sth-> finish (); Prawdopodobnie uratowałoby cię to od martwienia się o to. Mysql używa przestrzeni tmp systemu zamiast własnej przestrzeni.

sudo su


cd /var/log/mysql

i na koniec wpisz: > mysql-slow.log

To zadziałało dla mnie

Usuń bazę danych problemów, a następnie uruchom ponownie usługę mysql ( sudo service mysql restartna przykład).