Внимание!!! Все файлы в которых будут меняться настройки обязательно нужно копировать в созданную в корне сервера папку copy.

Новые настройки вступят в силу после рестарта необходимой службы.

Новые настройки, влияние которых на работу сервера в дальнейшем неизвестно, после проведенных работ заменять на исходные (возвращать на старые).

Удаление устаревших бинарных логов MySQL

Материал из Справка по MediaWiki
Перейти к: навигация, поиск

Тем, кто хоть раз имел дело с репликацией данных с одного MySQL сервера на другой известно понятие бинарных логов. Именно они передаются на SLAVE сервера для синхронизации данных. Но нужны они не только для этого. Они очень помогают при сбое сервера и внезапной его перезагрузке, тогда по бинарным логам MySQL может восстановить те данные, которые не успели попасть в хранилище. Но они не включены по умолчанию. И зачастую функция их автоматического удаления не настроена вообще. В результате при интенсивном юзании MySQL сервера вы можете столкнуться с проблемой нехватки места на диске.

Поэтому есть смысл сказать MySQL серверу, что старые логи всё-таки надо пилить. За это отвечает конфигурационный параметр expire_logs_days в серкции [mysqld] конфигурационного файла my.cnf.

expire_logs_days = 5

Теперь после перезапуска MySQL сервер уже будет знать какой древности логи уже стоить удалять (в приведённом примере период древности составляет 5 дней). Чтобы не ожидать когда он перезапустится можно просто подать запрос к серверу посредством phpMyAdmin или консольной программы mysql.

SET GLOBAL expire_logs_days=14;

На данные настройки MySQL может отреагировать не сразу. Поэтому если Вы куда-то спешите, можно произвести ручную зачистку логов до определённого времени используя такой запрос:

PURGE BINARY LOGS BEFORE '2013-01-13 00:00:00';

В запросе указывается дата-врема (в формате datetime) до которого логи нужно выпилить. Если логов накопилось много, то и места можно освободить много.