FLUSH LOGS뿐만 아니라 PURGE BINARY 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 MASTERPURGE BINARY LOGS 의 효과 와 두 가지 주요 차이점이 있습니다.

1. RESET MASTER 인덱스 파일에 나열된 모든 이진 로그 파일을 제거하고 숫자 접미사가 .000001 인 하나의 빈 이진 로그 파일 만 남겨두고 번호 매기기는 PURGE BINARY LOGS에 의해 재설정되지 않습니다.

2. RESET MASTER복제 슬레이브가 실행되는 동안에는 사용되지 않았습니다. RESET MASTER슬레이브가 실행되는 동안 사용되는 동작 은 정의되어 있지 않으므로 지원되지 않는 PURGE BINARY LOGS반면 복제 슬레이브가 실행되는 동안에는 안전하게 사용할 수 있습니다.

RolandoMySQLDBA의 경고

당신이 실행하는 경우 RESET MASTER노예 연결하고 실행하는 각 슬레이브의 IO 스레드는 즉시 그 자리를 잃게됩니다. 따라서 복제가 중단되고 모든 슬레이브의 데이터를 다시 동기화하기 위해 시간을 소비해야합니다. 복제 무결성을 손상시키지 않고 마스터에서 바이너리 로그를 안전하게 삭제하려면 다음을 수행하십시오.

• 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을 다시 시작하면 expire_logs_days설정 을 존중하기 위해 binlog 파일을 정리 하고 정상적으로 다시 작동하기 시작했습니다.

제 경우에는 PURGE BINARY단순히 아무것도 삭제하지 않았습니다.

나는 내가 한 첫 번째 일은 변화했다, 그래서 100 % 사용에서 내 파티션, (내 slowqueries를 다시 시작하는 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 = 로그를 삭제하지 않습니다.

( 소스 )