Как я спасал сервер от гибели: битва с переполнением /var

Друзья, вы когда-нибудь сталкивались с ситуацией, когда твой сервер начинает вести себя как старый утюг — не включается, не работает, а когда и включается, то пытается убить всё вокруг? Вот и я недавно оказался в такой ситуации. Всё началось с банальной, на первый взгляд, проблемы: переполнения /var. Но куда же мне было знать, что это станет началом великой битвы за сервер!

Стартовая ситуация: как я довёл сервер до кризиса

Как это часто бывает, я слишком долго игнорировал свою файловую систему. Сервер — как старый друг, который всегда рядом и ничего не просит. Но вот, вдруг, однажды, когда я захотел сделать пару мелких изменений, мой доблестный сервер сказал: “Ну всё, хватит!” и отказался работать. Апач не запускался. База данных? Тоже никак не реагировала. Заходим через ssh, а там… не хватает места в /var! Да так, что 100%.

Я как бы понял, что что-то пошло не так, но на тот момент у меня было только одно чувство: “Тоже мне, гуру администрирования, напоролся на такую ерунду!” Ну что ж, не будем о грустном, перейдём к эпопее.

Первая встреча с препятствием: где же место?

Я заглядываю в /var и вижу картину маслом: весь диск забит! 9,1 гигабайта, а из них 8,7 занято. Я как истинный администратор — решил действовать решительно. Проверил, что там в /var — а там блоки данных от Docker, базы данных и ещё куча всего. А дальше началась настоящая карусель.

Вот, например, MySQL. Я уверен, что все знают, что там может быть хранилище бинарных логов, которые могут расти до гигантских размеров. И я не был исключением. Я сразу понял: эти логи и зажали мне всё пространство! А так как MySQL в этот момент, мягко говоря, слегка «замёрз» из-за отсутствия места — я понял, что придётся решать эту проблему прямо сейчас.

Шаг второй: лечение бинарных логов

Проверил: binlog.000231, binlog.000230 — все эти файлы весили по 1,1 гигабайта. Похоже, я не то что сервер, а целый космос забил этими логами.

Что же делать? Конечно же, удалить их! Я, вдохновлённый успехом удаления, почистил их вручную. Но, как выяснилось, это ещё не было решением проблемы. Все логи остались в файловой системе, и, как следствие, не освободилось место.

Я попытался применить команду для очистки бинарных логов:

sudo mysql -u root -p -e "PURGE BINARY LOGS TO 'binlog.000232';"

Но… ничего не вышло. MySQL просто не реагировал. Сервер сидел, как тот глухой пёс, который не слышит своего хозяина. PHPMyAdmin тоже не заходил — ошибка при подключении, база данных отказала. Апач тоже стоял, как тот самый слоник на льду. Всё зависло. Паника!. Я начал думать, что всё, сервер не спасти. Но я решил не сдаваться. Пора было искать выход.

Шаг третий: настройка системы

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

[mysqld]
expire_logs_days = 7

Это было бы решением на будущее. Но что делать с текущими логами? Придётся их как-то почистить! Но поскольку MySQL и PHPMyAdmin отказались сотрудничать, пришлось копать глубже.

Шаг четвёртый: перезапуск и спасение

Вот тут и началась моя героическая часть. На мой страх и риск, я решил удалить более старые бинарные логи вручную, освободив около 1 гигабайта пространства. Логи типа binlog.000229, которые уже были старыми и не использовались, я удалил, надеясь на лучшее.

После этого я смог перезапустить MySQL и Apache, и… о чудо! Они не взорвались. Всё заработало, как надо. Но на этом я не остановился и продолжил убирать старые бинарные логи с помощью команды:

sudo mysql -u root -p -e "PURGE BINARY LOGS TO 'binlog.000232';"

Теперь сервер снова дышал. Всё продолжало работать, как часы, и я мог спокойно думать, как избежать этой проблемы в будущем.

Итог

И вот я снова наслаждаюсь спокойной работой сервера. Вдохновлённый успехом, я даже подумал: «А может, написать об этом статью?» Мораль сей басни такова: не оставляйте свои сервера без присмотра! А ещё настройте автоматическую очистку старых логов. Если вы не хотите оказаться на грани катастрофы, как это было со мной, ведь переполненная /var — это не шутки.

И, конечно же, если вдруг снова всё пойдёт не так — вам всегда помогут три вещи: команды PURGE, настройки expire_logs_days и нервное спокойствие (желательно не терять его в процессе).

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

Вот такая вот эпопея, друзья. Если будете решать проблему переполнения диска — вспомните меня и избегайте этих ошибок.