Я використовував 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з підключеними рабами і працюєте, нитка IO кожного підлеглого негайно втратить своє місце. Таким чином, реплікація порушена, і вам доведеться витратити час на отримання даних про всі Синхронізації знову. Якщо ви хочете безпечно видалити бінарні журнали з 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 став "пошкодженим" з невірними записами файлів бінлога.

Зокрема, файл індексу розпочався з 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();

Або замініть функцію ЗАРАЗ () на будь-яку дату в лапках:

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

Або ви можете автоматизувати цю дію за допомогою expire_logs_days = 10my.cnf. За замовчуванням expire_logs_days дорівнює 0 = ніколи не видаляйте журнали.

( джерело )