7.9 Debugging a MySQL Server

7.9.1 Debugging a MySQL Server

7.9.1.1 Compiling MySQL for Debugging
7.9.1.2 Creating Trace Files
7.9.1.3 Using WER with PDB to create a Windows crashdump
7.9.1.4 Debugging mysqld under gdb
7.9.1.5 Using a Stack Trace
7.9.1.6 Using Server Logs to Find Causes of Errors in mysqld
7.9.1.7 Making a Test Case If You Experience Table Corruption

MySQL에서 매우 새로운 기능을 사용하고 있다면, mysqld를 --skip-new 옵션과 함께 실행해 볼 수 있습니다(이 옵션은 잠재적으로 안전하지 않을 수 있는 모든 새로운 기능을 비활성화합니다).
Section B.3.3.3, “What to Do If MySQL Keeps Crashing”를 참조하십시오.

mysqld가 시작되려고 하지 않는다면, 설정을 방해하는 my.cnf 파일이 없는지 확인하십시오! mysqld --print-defaults로 my.cnf 인자를 확인할 수 있으며, mysqld --no-defaults ...로 시작하여 해당 인자 사용을 피할 수 있습니다.

mysqld가 CPU나 메모리를 과도하게 사용하기 시작하거나 “멈추는(hang)” 경우, mysqladmin processlist status를 사용하여 누군가가 오랜 시간이 걸리는 쿼리를 실행하고 있는지 확인할 수 있습니다. 성능 문제를 겪거나 새로운 클라이언트가 접속할 수 없는 문제가 있을 때는 어떤 창에서든 mysqladmin -i10 processlist status를 실행해 두는 것이 좋은 생각일 수 있습니다.

명령어 mysqladmin debug는 사용 중인 락, 사용된 메모리, 쿼리 사용량에 관한 일부 정보를 MySQL 로그 파일로 덤프합니다. 이는 일부 문제를 해결하는 데 도움이 될 수 있습니다. 이 명령어는 MySQL을 디버깅용으로 컴파일하지 않았더라도 몇 가지 유용한 정보도 제공합니다!

문제가 일부 테이블이 점점 느려지는 것이라면, OPTIMIZE TABLE이나 myisamchk로 해당 테이블을 최적화해야 합니다. Chapter 7, MySQL Server Administration를 참조하십시오. 또한 EXPLAIN으로 느린 쿼리도 점검해야 합니다.

환경에 고유할 수 있는 문제에 대해서는, 이 매뉴얼의 OS별 섹션도 읽어야 합니다. Section 2.1, “General Installation Guidance”를 참조하십시오.