1030 Ошибка 28 из движка хранилища

Я работаю над проектом, где мне нужно создать базу данных с 300 таблицами для каждого пользователя, который хочет увидеть демонстрационное приложение. он работал нормально, но сегодня, когда я тестировал нового пользователя, чтобы увидеть демо, он показал мне это сообщение об ошибке

1030 Got error 28 from storage engine

Потратив некоторое время на поиск в Google, я обнаружил, что это ошибка, связанная с пространством базы данных или временных файлов. Я пытался это исправить, но мне не удалось. Теперь я даже не могу запустить MySQL. Как я могу это исправить, и я также хотел бы увеличить размер до максимума, чтобы я не столкнулся с той же проблемой снова и снова.

Mysql ошибка « 28 из хранилища » - означает « недостаточно места на диске ».

Чтобы показать место на диске, используйте команду ниже.

myServer# df -h

Результаты должны быть такими.

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

Чтобы расширить это (хотя это старый вопрос); Речь идет, вероятно, не о самом пространстве MySQL, а о пространстве в целом, с учетом файлов tmp или чего-то в этом роде. Мой каталог данных mysql не был заполнен, раздел / (root) был

У меня была такая же проблема в AWS RDS. Это было связано с тем, что свободное пространство (место на жестком диске) было заполнено. Вам нужно увеличить свое пространство или удалить некоторые данные.

Мой / tmp был% 100. После удаления всех файлов и перезапуска MySQL все работало нормально.

Моя папка / var / log / apache2 была 35 г, а некоторые журналы в / var / log составляли остальные 5 г моего жесткого диска 40 г. Я очистил все журналы * .gz и, убедившись, что другие журналы не будут делать плохие вещи, если я их испортил, я просто очистил их тоже.

echo "clear" > access.log

и т.п.

Проверьте / резервную копию, чтобы увидеть, если вы можете удалить более старую ненужную резервную копию.

У меня была похожая проблема из-за моих двоичных журналов репликации .

Если это так, просто создайте cronjob для выполнения этого запроса каждый день:

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

Это удалит все двоичные журналы старше 2 дней.

Я нашел это решение здесь .

Простое: $ sth-> finish (); Возможно, избавит вас от беспокойства по этому поводу. Mysql использует системное пространство tmp вместо собственного пространства.

sudo su


cd /var/log/mysql

и, наконец, введите: > mysql-slow.log

Это сработало для меня

Удалите проблемную базу данных, затем перезагрузите службу mysql ( sudo service mysql restartнапример).