삭제는 MySQL 로그인 문제 레코드

51 전, DBA 동료 피드백 (가정 10 G 위의 파일 크기), 큰 느린 로그 파일을 삭제 하 고 다음에 MySQL, 플러시 느린 로그를 실행 하는 일상적인 환경에서 찾을 것입니다 mysqld 라이브.

오늘 문제를 재현 하 고, 여기 왜에 대 한 간략 한 분석이입니다.

재발 단계:

1. 생성 느린 로그 (0으로 설정된 Long_query_time);

2. 관찰 삭제 rm 느린 로그 순간, TPS 또는 QPS 변화;

3. 관찰 플러시 느린 로그 실행 순간, TPS 또는 QPS 변경;

4. 레코드 플러시 느린 기록 실행, pstack 호출 스택;

첫 번째 단계, 아무것도 말할 수 있다.

두 번째 단계, Tps 또는 qps 변화 없음.

세 번째 단계는 TPS 또는 QPS 상품 0 순식간에 다음과 같이 찾을 수 있습니다.

MySQL 커맨드 라인 플러시 느린 로그 실행 시간 그냥 약 3s는 발견.

4 단계에서 우리는 Pstack의 출력에서 모양과 관련 기록:

그 http://www.aliyun.com/zixun/aggregation/29914.html을 찾을 것입니다 "> 플러시 느린 로그 작업을 수행 하는 스레드 2 그리고 다른 스레드가 잠금 lock_log에 대 한 기다리고 있습니다.

셸에서 RM 느린 로그 작업을 수행할 때이 뒤에 이유는 실제로 매우 간단, Mysqld 여전히 파일을 열 파일 핸들을가지고 있기 때문에 파일은 삭제 되지 않습니다. 플러시를 수행 1 close 실제로 수행 하는 로그 작업; 2) (Logger.flush_slow_log-mysql_slow_log.reopen_file) 오픈 작업 닫기 작업이 실행 될 때, 파일 시스템은 실제로 어느 시점에서 스레드 차지 Lock_log 잠금 파일을 삭제 합니다.

제거 브러시 더러운 (물론 나 내용이 파일 시스템 캐시에서이 장면은 매우 극단적인, 기본적으로 모든 느린 로그 파일 생성)을 수행할 것입니다, 그리고이 시간이 될 것입니다, 그리고이 문장은 3s 소비와 같은 실행. 이 시간 동안, 연결 문으로 전송 로그인 하는 경우 (서버 계층 로그: 느린 로그/binlog/일반 로그 lock_log의 총이이 잠금) 시스템 외부 응답을 살고 다음 대기 상태에 있을 것입니다.

플러시 느린 로그에서 닫기 실행 하 고 파일 시스템 캐시에서 해당 파일의 커밋되지 않은 페이지 비율을 호출 하는 데 필요한 시간 및 파일 크기 예를 들어 내가 사용 빈 느린 로그 플러시 sysctl vm.drop_caches=3를 실행 하기 전에

파일 시스템 캐시의 플러시 느린 로그 작업 시간 같은 크기 0.42s, 해당 차단 시간이 많이 감소 될 것 이다.

고려에 posix_fadvise 호출을 실행 느린 로그 파일 핸들, (느린 로그는 캐시 또한 필요가 있다) 매우 큰 로그 파일 콘텐츠를 캐시 하지 합니다,이 문서는 텍스트의 마스터, 다음 posix_fadvise 캐시 지우기 오해 및 개선 조치를 참조할 수 있습니다.

또한, 피터 07에서이 문제를 논의 mysqld 보다는 스스로 진짜 삭제 동작 완료 있도록 MySQL 로그 추천 첫 번째 뮤직 비디오 파일은 다음 로그를 플러시할 및 다음 삭제 파일 작업을 수행 회전 조심. 더 유감 스럽게도, 7 년 후, lock_log 잠금 문제 하지 완전히 해결 되었습니다.

추 신:

문서 끝에 메모를 작성, 닫기/rm 작업을 통해 10 G 크기의 파일을 삭제 하 고 캐시 비우기 sysctl vm.drop_caches=3을 수행한 후 작업은 여전히 백 밀리초 규모 (내 컴퓨터는 200ms +), 그것은 뒤에 동료 커널 그룹에 의해 이해 될 필요가 있다.