MySQL은 미친 오류 로그를 작성합니다-컴퓨터 지식-php.cn

MySQL 狂写错误日志

핵심 비즈니스 데이터베이스, 버전은 MySQL 8.34
Community Server Edition입니다. 출시 이후 이 데이터베이스 서버의 오류 로그는 매우 빠르게 증가하여(아래 그림 참조) 24시간마다 10G
이상의 용량으로 증가했습니다.

장애알람이 발생하여 정상적인 업무접근에는 영향을 미치지 않았으므로 해당 담당자는 MySQL

서비스를 재시작할 수 없습니다. 이러한 상황을 고려하여 매일 밤 정해진 시간에 이러한 로그를 정리하는 자동 예약 작업을 설정해야 했습니다. 특정 작업의 경우 시스템 명령줄에서 "crontab -e"

를 실행하고 다음 텍스트 줄을 추가하세요.

00 01 * * * 에코 > /data/mysql8/data/mysql_db/mysql.log 저장하고 편집 모드를 종료하면 작업의 정확성과 유효성을 확인해야 하는 경우 실행 시간을 상당히 최근 시점으로 수정한 다음 오류 로그 파일 "mysql.log

"을 전후로 비교할 수 있습니다. 아래 그림과 같이 작업 실행 크기를 확인하고 cron

로그를 확인하여 이 예약된 작업이 실행되었는지 확인하세요.

춘절 연휴라 다들 집에 돌아가서 새해를 맞이하는데, 이때가 방문 횟수가 가장 적은 시기이기 때문에 이 문제를 완전히 해결하려고 합니다. 관련 담당자의 의견을 듣고 쓸모없는 경고 출력을 차단하기 위해 MySQL

options 파일을 수정하는 것이 가능한지 문의하십시오. 대답은 "

다시 시작하는 데 얼마나 걸리나요?"
였습니다. 대답은 "
몇 분이면 충분합니다"
입니다.

이 정의된 오류 로그에는 무엇이 대량으로 기록되나요? "mysql.log"

대용량 파일을 열고 경고 메시지로 가득 찬 것을 확인하세요. 시스템 명령 "tail -f mysql.log"

를 사용하면 화면 출력이 모터 플라이휠처럼 굴러갑니다. 아래 그림.

이 경고 메시지는 사용자 계정이 기본 인증 방법 "caching_sha2_password"

와 일치하지 않는 "mysql_native_password"
를 사용하고 있음을 나타냅니다. 해결 방법은 모든 사용자 계정의 비밀번호 인증 방법을 "
caching_sha2_password"
로 변경하거나 오류 로그 파일 "mysql.log"
에 이러한 경고 메시지를 기록하지 않는 것입니다. 사용자 계정이 많고 비즈니스가 여러 개 설계되어 있으므로 경고 메시지를 기록하지 않는 것이 더 쉽습니다. 어쨌든 이러한 경고 메시지는 쓸모가 없습니다. 실제 오류 로그를 기록하면 문제 해결에 도움이 됩니다.

MySQL

서버가 위치한 호스트 시스템 Centos 7,

텍스트 편집기에서 옵션 파일 "/etc/my.cnf"
를 열고 텍스트 블록 [mysqld
]에 다음 텍스트 줄을 추가합니다.

로그-오류-상세=1

기본적으로 MySQL 8

의 "log-error-verbosity"

값은 "3"
입니다. 이는 모든 "
오류, 경고 및 설명"
이 오류 로그에 기록된다는 의미입니다. 숫자 "2
"은 "오류 및 경고" 로깅을 의미하고, 숫자 "1
"은 "오류"만 로깅을 의미합니다.

옵션 파일을 수정하기 전에 반드시 파일을 먼저 백업해 두시기 바랍니다. 이는 상식이자 후회의 약입니다. 쓰기 오류가 없는지 확인한 후 MySQL

서비스를 다시 시작하고 로컬 MySQL

서비스가 정상인지, 원격 마스터-슬레이브 동기화가 정상인지, 지연이 있는지 확인합니다.

몇 분 동안 실행한 후 MySQL

의 오류 로그를 확인하여 더 이상 빠르게 성장하지 않는지 확인하세요. 일정 기간 관찰한 결과 MySQL 경고 로그가 더 이상 기록되지 않고, 파일 증가율도 크게 감소한 것이 사실입니다.