Я использовал PURGE BINARY LOGS, а также FLUSH LOGS, но каталог mysql по-прежнему содержит следующие файлы:

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

Есть ли причина, по которой использование команд не работает? Эти файлы занимают много места. Я хотел бы избавиться от них безопасно.

PURGE BINARY LOGSОператор удаляет все бинарные файлы журналов , перечисленные в индексном файле журнала до указанного имени файла журнала или временную метку. Удаленные файлы журнала также удаляются из списка, записанного в индексном файле, так что данный файл журнала становится первым в списке.

Я надеюсь, что вы удалили двоичные журналы mysql-bin.000019с помощью команды

PURGE BINARY LOGS TO 'mysql-bin.000019';

Если вам нужно очистить все журналы, как

PURGE BINARY LOGS TO 'mysql-bin.000025';

Это удалит двоичные журналы до mysql-bin.000025.

ОБНОВИТЬ

Можешь попробовать

RESET MASTER;

RESET MASTER Удаляет все двоичные файлы журнала, перечисленные в файле индекса, сбрасывает двоичный файл журнала журнала, чтобы быть пустым, и создает новый двоичный файл журнала

Эффект RESET MASTERот PURGE BINARY LOGS отличается от двух основных:

1. RESET MASTER удаляет все двоичные файлы журнала, перечисленные в файле индекса, оставляя только один пустой двоичный файл журнала с числовым суффиксом .000001, тогда как нумерация не сбрасывается с помощью PURGE BINARY LOGS.

2. RESET MASTERне предназначался для использования во время работы любых подчиненных устройств репликации. Поведение RESET MASTERпри использовании во время работы ведомых устройств не определено (и, следовательно, не поддерживается), тогда как PURGE BINARY LOGSможет безопасно использоваться во время работы ведомых устройств репликации.

CAVEAT от RolandoMySQLDBA

Если вы работаете RESET MASTERс подключенными и работающими подчиненными, поток ввода-вывода каждого подчиненного немедленно теряет свое место. Репликация, таким образом, нарушена, и вам придется потратить время на повторную синхронизацию данных на всех подчиненных устройствах. Если вы хотите безопасно удалить двоичные журналы с мастера, не нарушая целостность репликации, вот что вы делаете:

• Беги SHOW SLAVE STATUS\Gна каждого Раба.
• Принять к сведению Relay_Master_Log_File. Это двоичный журнал, последний оператор которого был успешно выполнен в подчиненном).
• Из всех отображений SHOW SLAVE STATUS\Gопределите, какой из Relay_Master_Log_Fileних самый старый (например, «mysql-bin.00123»).
• Вы можете запустить PURGE BINARY LOGS TO 'mysql-bin.00123';Ни один из Рабов не потеряет свое место.

Общий эффект? Это оставит двоичные журналы на ведущем устройстве, чьи операторы еще не были выполнены на всех подчиненных устройствах.

Я не уверен, что это случилось с вами, но в моем случае MySQL прекратил «циклическое» ведение журналов, и файл mysql-bin.index стал «поврежденным» из-за недопустимых записей файла binlog.

В частности, индексный файл начинался с mysql-bin.000001 и доходил до mysql-bin.000220, но затем снова начинался с 001. Когда я сравнил это с файлами на моем сервере, я увидел, что у меня есть файлы с 001 по 022.

Сначала я попытался, PURGE LOGS TO 'mysql-bin.000022';но это не сработало.

В конце я остановил MySQL и вручную отредактировал индексный файл, пока он не совпал с файлами на моем сервере. Когда я перезапустил MySQL, он очистил файлы binlog в соответствии с expire_logs_daysнастройками и снова начал нормально работать.

В моем случае PURGE BINARYпросто ничего не удалялось.

Мой раздел использовался на 100% (мне пришлось немного почистить журнал медленных запросов, чтобы было достаточно места для перезапуска mysql), поэтому первое, что я сделал, было изменение, /etc/my.cnfчтобы прокомментировать строку log-bin=mysql-bin(в этом не было необходимости) на этом сервере, и я забыл удалить его), а затем я перезапустил mysql (это было необходимо, потому что в очереди были запросы, которые мешали PURGE BINARYвыполнению).

После этого я побежал, PURGE BINARYно ничего не случилось. Поэтому я прочитал руководство и выяснил, что:

Этот оператор не действует, если сервер не был запущен с параметром --log-bin, чтобы включить двоичное ведение журнала.

Таким образом, я снова включил log-bin=mysql-binмой /etc/my.cnf, перезапустил, очистил файлы (теперь с успехом), снова прокомментировал строку и затем перезапустил. После этого файлы были удалены и больше не создавались.

Это работает для меня: (версия сервера MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Удаляет все двоичные журналы в моей системе.

Вы можете легко удалить ВСЕ журналы с помощью:

PURGE BINARY LOGS BEFORE NOW();

Или замените func NOW () на любую дату в кавычках:

PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

Или вы можете автоматизировать это действие с помощью expire_logs_days = 10my.cnf. По умолчанию expire_logs_days равно 0 = никогда не удалять журналы.

( источник )