Имея собственный сервер, где установлен mysql, мы иногда замечаем, что место куда-то уходит. После недолгих поисков обнаруживаем в папке /var/lib/mysql (CentOS, RHEL) или в подобной, где установлен mysql файлы mysql-bin.000010, mysql-bin.000001, mysql-bin.000002, размер которых достигает до гигабайта.

Попробуем разобраться с этой ситуацией

Это бинарные логи операций в mysql, которые имеют две функции. Обратимся к документации mysql:

The binary log also contains information about how long each statement took that updated data. The binary log has two important purposes:For replication, the binary log on a master replication server provides a record of the data changes to be sent to slave servers. The master server sends the events contained in its binary log to its slaves, which execute those events to make the same data changes that were made on the master.Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup.

Т.е. 1 применение — для репликации БД, когда у нас есть несколько баз данных, настроенных на репликацию. И 2 применение — для восстановления данных в случае сбоя.

Меня волновал по крайней мере 2 пункт, поэтому полностью удалять эти логи не стоит. Рассмотрим разные способы:

1. Выставление ротации бинарных логов

   Прописать в my.conf (my.cnf) строчку expire_logs_days = 5, которая гласит, что время хранения логов — 5 дней. После выставления этого параметра и перезагрузки mysqld сервера устаревшие файлы были удалены.

2. Ручное удаление

   PURGE BINARY LOGS TO ‘mysql-bin.010’; PURGE BINARY LOGS BEFORE ‘2014-02-02 22:46:26’;

   В данном случае мы удаляем конкретный бинарный лог или по дате.

3. Ручное удаление с проверкой используемых бинарных логах на slave серверах

   Чтобы репликация успешно завершилась до удаления логов, необходимо проверить — какие данные уже реплицировались на slave сервера
   Для просмотра состояния репликации и какой файл еще используется подсмотрим действия в документации.

   To safely purge binary log files, follow this procedure:
   1. On each slave server, use SHOW SLAVE STATUS to check which log file it is reading.
   2. Obtain a listing of the binary log files on the master server with SHOW BINARY LOGS.
   3. Determine the earliest log file among all the slaves. This is the target file. If all the slaves are up to date, this is the last log file on the list.
   4.Make a backup of all the log files you are about to delete. (This step is optional, but always advisable.)
   5.Purge all log files up to but not including the target file.

   Т.е. проверяем состояния репликации на slave серверах, просматриваем бинарные логи на master сервере, определить самый ранний файл, который используется на slave сервере и удалить более старые способом из п.2.
   Но обычно, хватает способа из п.1, если не ставить слишком малые значения.
   Если репликация уже Вам не нужна, то можно сделать:

   reset master; stop master;

   Источник