Użyłem PURGE BINARY LOGS, a także FLUSH LOGS, ale katalog mysql nadal zawiera te pliki:

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

Czy istnieje powód, dla którego używanie poleceń nie działa? Te pliki zajmują dużo miejsca. Chciałbym się ich bezpiecznie pozbyć.

PURGE BINARY LOGSOświadczenie usuwa wszystkie binarne pliki dziennika wymienione w pliku indeksu dziennika przed Określona nazwa pliku dziennika lub datownik. Usunięte pliki dziennika są również usuwane z listy zapisanej w pliku indeksu, dzięki czemu dany plik dziennika staje się pierwszym na liście.

Mam nadzieję, że wyczyściłeś dzienniki binarne, mysql-bin.000019używając polecenia

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

Jeśli chcesz wyczyścić wszystkie dzienniki, polub to

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

Spowoduje to usunięcie dzienników binarnych do góry mysql-bin.000025.

AKTUALIZACJA

Możesz spróbować

RESET MASTER;

RESET MASTER Usuwa wszystkie pliki dziennika binarnego wymienione w pliku indeksu, resetuje plik indeksu dziennika binarnego do pustego i tworzy nowy plik dziennika binarnego

Efekty RESET MASTERróżnią się od efektów WYPEŁNIANIA DZIENNIKÓW BINARNYCH na 2 kluczowe sposoby:

1. RESET MASTER usuwa wszystkie binarne pliki dziennika wymienione w pliku indeksu, pozostawiając tylko jeden pusty, binarny plik dziennika z sufiksem numerycznym .000001, podczas gdy numeracja nie jest resetowana przez PURGE BINARY LOGS.

2. RESET MASTERnie był przeznaczony do użycia podczas działania jakichkolwiek urządzeń podrzędnych replikacji. Zachowanie, RESET MASTERgdy jest używane podczas pracy urządzeń podrzędnych, jest niezdefiniowane (a zatem nieobsługiwane), podczas gdy PURGE BINARY LOGSmoże być bezpiecznie używane podczas pracy urządzeń podrzędnych replikacji.

CAVEAT autorstwa RolandoMySQLDBA

Jeśli biegniesz RESET MASTERz podłączonymi i uruchomionymi Slave, wątek IO każdego Slave natychmiast straci swoje miejsce. Replikacja jest w ten sposób zepsuta i będziesz musiał poświęcić czas na ponowne zsynchronizowanie danych na wszystkich urządzeniach slave. Jeśli chcesz bezpiecznie usunąć dzienniki binarne z serwera głównego bez naruszenia integralności replikacji, wykonaj następujące czynności:

• Uruchom SHOW SLAVE STATUS\Gna każdym Slave.
• Zwróć uwagę na Relay_Master_Log_File. Jest to dziennik binarny, którego najnowsza instrukcja została pomyślnie wykonana w Slave).
• Na wszystkich ekranach SHOW SLAVE STATUS\Gokreśl, który Relay_Master_Log_Filejest najstarszy (na przykład „mysql-bin.00123”).
• Możesz uruchomić PURGE BINARY LOGS TO 'mysql-bin.00123';Żadna z Niewolników nie straci swojego miejsca.

Ogólny efekt? Spowoduje to pozostawienie dzienników binarnych w Panu, którego instrukcje jeszcze nie zostały wykonane we wszystkich Niewolnikach.

Nie jestem pewien, czy tak się stało, ale w moim przypadku MySQL zatrzymał dzienniki „cykliczne”, a plik mysql-bin.index stał się „uszkodzony” przez nieprawidłowe wpisy pliku binlog.

W szczególności plik indeksu rozpoczął się od mysql-bin.000001 i dotarł do mysql-bin.000220, ale potem jakoś zaczął się od 001. Kiedy porównałem to do plików na moim serwerze, zauważyłem, że mam pliki od 001 do 022

Na początku próbowałem, PURGE LOGS TO 'mysql-bin.000022';ale to nie działało.

W końcu zatrzymałem MySQL i ręcznie edytowałem plik indeksu, aż pasował do plików, które miałem na moim serwerze. Kiedy zrestartowałem MySQL, wyczyściłem pliki binlog, aby zachować zgodność z expire_logs_daysustawieniami i zacząłem normalnie działać.

W moim przypadku PURGE BINARYpo prostu niczego nie usunąłem.

Miałem partycję przy 100% obciążeniu (musiałem trochę wyczyścić mój dziennik wolniejszych zapytań, aby było wystarczająco dużo miejsca na mysql do ponownego uruchomienia), więc pierwszą rzeczą, którą zrobiłem, było /etc/my.cnfskomentowanie linii log-bin=mysql-bin(nie było to konieczne na tym serwerze i zapomniałem go usunąć), a następnie zrestartowałem mysql (było to potrzebne, ponieważ w kolejce były zapytania uniemożliwiające PURGE BINARYwykonanie).

Potem pobiegłem, PURGE BINARYale nic się nie stało. Przeczytałem więc instrukcję i dowiedziałem się, że:

Ta instrukcja nie ma wpływu, jeśli serwer nie został uruchomiony z opcją --log-bin, aby włączyć rejestrowanie binarne.

Więc ponownie włączyłem log-bin=mysql-binw moim /etc/my.cnf, zrestartowałem, OCZYSZCZałem pliki (teraz z sukcesem), ponownie skomentowałem linię, a następnie uruchomiłem ponownie. Następnie pliki zostały usunięte i nie są już tworzone.

To działa dla mnie: (wersja serwera MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Usuwa wszystkie dzienniki binarne z mojego systemu.

Możesz łatwo usunąć WSZYSTKIE dzienniki za pomocą:

PURGE BINARY LOGS BEFORE NOW();

Lub zastąp func NOW () dowolną datą w cudzysłowie:

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

Lub możesz zautomatyzować tę akcję za pomocą expire_logs_days = 10my.cnf. Domyślnie expire_logs_days ma wartość 0 = nigdy nie usuwaj dzienników.

( źródło )