Loading...
MySQL 9.5 Reference Manual 9.5의 1.6 How to Report Bugs or Problems의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
문제와 관련된 bug report를 게시하기 전에, 그것이 실제 bug인지, 그리고 이미 보고된 적이 없는지를 먼저 확인해 보십시오:
먼저 MySQL 온라인 매뉴얼 https://dev.mysql.com/doc/에서 검색을 시작하십시오. 새로 발견된 문제에 대한 해결 방법을 자주 추가하여 매뉴얼을 최신 상태로 유지하려고 노력하고 있습니다. 또한 매뉴얼에 포함된 릴리스 노트는 특히 유용할 수 있는데, 더 최신 버전에 당신의 문제에 대한 해결 방법이 포함되어 있을 가능성이 충분히 있기 때문입니다. 릴리스 노트는 매뉴얼과 동일한 위치에서 제공됩니다.
SQL 문에 대해 파스 오류가 발생한다면, 구문을 주의 깊게 확인하십시오. 그 안에서 잘못된 점을 찾을 수 없다면, 현재 사용 중인 MySQL Server 버전이 당신이 사용 중인 구문을 지원하지 않을 가능성이 매우 높습니다. 최신 버전을 사용 중이고 매뉴얼에 당신이 사용 중인 구문에 대한 설명이 없다면, MySQL Server는 해당 문을 지원하지 않는 것입니다.
매뉴얼이 사용 중인 구문을 다루고 있지만 MySQL Server 버전이 오래된 경우, 그 구문이 언제 구현되었는지 확인하기 위해 MySQL 변경 이력을 확인해야 합니다. 이 경우, 더 최신 버전의 MySQL Server로 업그레이드할 수 있습니다.
일부 일반적인 문제에 대한 해결 방법은 Section B.3, “Problems and Common Errors”를 참조하십시오.
bug가 보고되었는지, 그리고 수정되었는지 확인하기 위해 http://bugs.mysql.com/의 bug 데이터베이스를 검색하십시오.
또한 http://www.mysql.com/search/를 사용하여 MySQL 웹사이트에 위치한 모든 웹 페이지(수동 포함)를 검색할 수 있습니다.
매뉴얼, bug 데이터베이스, 메일링 리스트 아카이브 어디에서도 답을 찾지 못한다면, 로컬 MySQL 전문가에게 확인하십시오. 그래도 질문에 대한 답을 찾지 못한다면, bug를 보고할 때 다음 지침을 사용하십시오.
bug를 보고하는 일반적인 방법은 bug 데이터베이스 주소인 http://bugs.mysql.com/ 사이트를 방문하는 것입니다. 이 데이터베이스는 공개되어 있으며 누구나 검색 및 열람할 수 있습니다. 시스템에 로그인하면 새로운 report를 입력할 수 있습니다.
http://bugs.mysql.com/의 bug 데이터베이스에 게시된 bug 중 특정 릴리스에서 수정된 항목은 릴리스 노트에 표시됩니다.
MySQL Server에서 보안 bug를 발견하면, 즉시 이메일 메시지를
<[email protected]>으로 보내 알려 주십시오. 예외: Support 고객은 보안 bug를 포함한 모든 문제를 http://support.oracle.com/의 Oracle Support에 보고해야 합니다.
다른 사용자들과 문제를 토론하려면 MySQL Community Slack을 사용할 수 있습니다.
좋은 bug report를 작성하려면 인내심이 필요하지만, 처음부터 제대로 작성해 두면 우리와 당신 모두의 시간을 절약할 수 있습니다. bug에 대한 완전한 테스트 케이스를 포함한 좋은 bug report는 다음 릴리스에서 bug가 수정될 가능성을 매우 높여 줍니다.
이 section은 report 작성을 올바르게 할 수 있도록 도와주며, 우리에게 별로 도움이 되지 않거나 전혀 도움이 되지 않는 일을 하느라 당신의 시간을 낭비하지 않도록 합니다. 이 section을 주의 깊게 읽고, 여기에 설명된 모든 정보가 report에 포함되도록 하십시오.
가능하면 bug를 게시하기 전에 최신 프로덕션 또는 개발 버전의 MySQL Server에서 해당 문제를 테스트해야 합니다. 누구나 당신의 테스트 케이스에 대해 mysql test < script_file을 실행하거나 bug report에 포함한 셸 혹은 Perl 스크립트를 실행하는 것만으로 bug를 재현할 수 있어야 합니다. 우리가 재현할 수 있는 모든 bug는 다음 MySQL 릴리스에서 수정될 가능성이 매우 높습니다.
bug report에 문제에 대한 좋은 설명이 포함되어 있을 때 가장 도움이 됩니다. 즉, 문제에 이르기까지 당신이 수행한 모든 작업의 좋은 예제를 제공하고, 문제 자체를 정확한 세부 사항과 함께 설명하십시오.
가장 좋은 report는 bug나 문제를 재현하는 전체 예제를 포함하는 report입니다. Section 7.9, “Debugging MySQL”을 참조하십시오.
너무 많은 정보를 포함한 report에 대해서는 우리가 대응할 수 있지만, 정보가 너무 적은 report에는 대응할 수 없다는 점을 기억하십시오. 사람들은 종종 문제의 원인을 알고 있다고 생각하여 어떤 세부 사항은 중요하지 않다고 가정하고 사실을 생략합니다.
따르기 좋은 원칙은 어떤 내용을 명시해야 할지 확신이 서지 않는다면, 명시하라는 것입니다. 처음 report에서 빠진 정보를 나중에 요청해야 해서 답변을 더 오래 기다리게 되는 것보다는 report에 두세 줄을 더 적는 편이 더 빠르고 덜 번거롭습니다.
bug report에서 가장 흔하게 발생하는 오류는 (a) 사용 중인 MySQL 배포판의 버전 번호를 포함하지 않는 것, (b) MySQL server가 설치된 플랫폼에 대한 플랫폼 유형과 버전 번호를 포함한 전체 설명을 생략하는 것입니다. 이 정보들은 매우 중요한 정보이며, 100건 중 99건에서 bug report는 이 정보 없이 쓸모가 없습니다.
“왜 이게 나에게는 동작하지 않나요?”와 같은 질문을 자주 받습니다. 그러면 해당 기능이 그 MySQL 버전에는 구현되어 있지 않다거나, report에 설명된 bug가 더 최신 MySQL 버전에서 이미 수정되었다는 사실을 알게 됩니다.
오류는 종종 플랫폼에 따라 달라집니다. 이런 경우, 운영 체제와 플랫폼의 버전 번호를 모르면 우리는 아무 것도 고치기 거의 불가능합니다.
소스로부터 MySQL을 컴파일했다면, 문제가 컴파일러와 관련이 있는 경우 컴파일러에 대한 정보도 제공해야 합니다. 사람들은 종종 컴파일러에서 bug를 발견하고 이를 MySQL 관련 문제라고 생각합니다.
대부분의 컴파일러는 항상 개발 중이며, 버전이 올라갈수록 더 나아집니다. 문제가 컴파일러에 의존하는지 판단하려면, 어떤 컴파일러를 사용했는지 알아야 합니다. 모든 컴파일 관련 문제는 bug로 간주하고 그에 맞게 report해야 합니다.
프로그램이 오류 메시지를 출력하는 경우, report에 이 메시지를 포함하는 것이 매우 중요합니다. 아카이브에서 무언가를 검색하려 할 때, report된 오류 메시지가 프로그램이 실제로 출력한 메시지와 정확히 일치하는 것이 더 좋습니다(심지어 대소문자까지도 일치해야 합니다). 전체 오류 메시지를 report에 복사 & 붙여넣기 하는 것이 가장 좋습니다. 메모리에 의존해 메시지를 다시 만들어서는 안 됩니다.
Connector/ODBC(MyODBC)에 문제가 있는 경우, 트레이스 파일을 생성하여 report에 함께 보내도록 하십시오. How to Report Connector/ODBC Problems or Bugs를 참조하십시오.
bug report에 mysql 커맨드라인 도구로 실행한 테스트 케이스에서 나온 긴 쿼리 출력 라인이 포함되는 경우,
--vertical 옵션이나 \G 문 종료자를 사용하여 출력 결과를 더 읽기 쉽게 만들 수 있습니다.
이 section 뒷부분의
EXPLAIN SELECT 예제는 \G 사용법을 보여 줍니다.
report에는 다음 정보를 포함시키십시오:
사용 중인 MySQL 배포판의 버전 번호(예: MySQL 5.7.10). 실행 중인 버전은
mysqladmin version을 실행하여 확인할 수 있습니다.
mysqladmin 프로그램은 MySQL 설치 디렉터리 하위의 bin 디렉터리에서 찾을 수 있습니다.
문제가 발생하는 머신의 제조사와 모델.
운영 체제 이름과 버전. Windows에서 작업하는 경우, 일반적으로 “내 컴퓨터” 아이콘을 더블클릭하여 “Help/About Windows” 메뉴를 열면 이름과 버전 번호를 알 수 있습니다. 대부분의 유닉스 계열 운영 체제에서는 uname -a 명령을 실행하면 이 정보를 얻을 수 있습니다.
메모리 양(실메모리 및 가상 메모리)이 관련되는 경우도 있습니다. 확실하지 않을 때는 이 값들을 포함하십시오.
MySQL 설치에서 docs/INFO_BIN 파일의 내용. 이 파일에는 MySQL이 어떻게 구성 및 컴파일되었는지에 대한 정보가 포함되어 있습니다.
MySQL 소프트웨어의 소스 배포판을 사용하는 경우, 사용한 컴파일러의 이름과 버전 번호를 포함하십시오. 바이너리 배포판을 사용하는 경우, 배포판 이름을 포함하십시오.
컴파일 중에 문제가 발생하면, 정확한 오류 메시지와 문제가 발생한 파일에서 해당 코드 주변의 몇 줄도 포함하십시오.
mysqld가 죽었다면, mysqld가 예기치 않게 종료되게 만든 문도 보고해야 합니다. 일반적으로 쿼리 로깅을 활성화한 상태로 mysqld를 실행한 다음, mysqld가 종료된 후 로그를 확인하면 이 정보를 얻을 수 있습니다. Section 7.9, “Debugging MySQL”을 참조하십시오.
데이터베이스 테이블이 문제와 관련되어 있으면, bug report에 SHOW CREATE TABLE db_name.tbl_name
문장의 출력을 포함시키십시오. 이는 데이터베이스에서 임의의 테이블 정의를 얻는 매우 쉬운 방법입니다. 이 정보는 당신이 경험한 상황과 동일한 상황을 만드는 데 도움이 됩니다.
문제가 발생했을 때의 SQL 모드가 중요한 경우가 많으므로,
sql_mode 시스템 변수의 값을 report해 주십시오. 저장 프로시저, 저장 함수, 트리거 객체의 경우, 관련
sql_mode 값은 객체가 생성될 때의 값입니다. 저장 프로시저 또는 함수의 경우,
SHOW CREATE PROCEDURE 또는
SHOW CREATE FUNCTION 문장에서 관련 SQL 모드를 확인할 수 있으며, 또는 INFORMATION_SCHEMA를 쿼리하여 이 정보를 얻을 수 있습니다:
1SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE 2FROM INFORMATION_SCHEMA.ROUTINES;
트리거의 경우, 다음 문을 사용할 수 있습니다:
1SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE 2FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT 문과 관련된 문제의 경우 항상 EXPLAIN SELECT ...의 출력과 해당
SELECT 문이 반환하는 행 수를 포함해야 합니다. 또한, 관련된 각 테이블에 대해 SHOW CREATE TABLE tbl_name의 출력도 포함해야 합니다. 상황에 대해 제공하는 정보가 많을수록 누군가가 도와줄 수 있는 가능성이 높아집니다.다음은 매우 좋은 bug report의 예입니다. 이 문들은
mysql
커맨드라인 도구를 사용해 실행됩니다. 읽기 어려운 매우 긴 출력 라인을 생성할 문에 대해 \G 문 종료자를 사용한 점에 주목하십시오.
1mysql> SHOW VARIABLES; 2mysql> SHOW COLUMNS FROM ...\G 3 <output from SHOW COLUMNS> 4mysql> EXPLAIN SELECT ...\G 5 <output from EXPLAIN> 6mysql> FLUSH STATUS; 7mysql> SELECT ...; 8 <A short version of the output from SELECT, 9 including the time taken to run the query> 10mysql> SHOW STATUS; 11 <output from SHOW STATUS>
스크립트를 제공할 수 없다면, 최소한 시스템 성능에 대한 정보를 제공하기 위해 report에 mysqladmin variables extended-status processlist의 출력을 포함해야 합니다.
몇 개의 행만으로 테스트 케이스를 만들 수 없거나, 테스트 테이블이 bug report에 포함하기에는 너무 큰 경우(10행 초과), 테이블을
mysqldump를 사용해 덤프하고 문제를 설명하는 README 파일을 만듭니다. 그런 다음 tar와 gzip 또는 zip을 사용하여 파일의 압축 아카이브를 생성합니다. http://bugs.mysql.com/의 bug 데이터베이스에 대한 bug report를 생성한 후, bug report에서 Files 탭을 클릭하여 아카이브를 bug 데이터베이스로 업로드하는 방법에 대한 지침을 확인하십시오.
MySQL server가 어떤 문에 대해 이상한 결과를 반환한다고 생각되면, 실제 결과뿐만 아니라 기대하는 결과와 그 기대의 근거에 대한 설명도 함께 포함하십시오.
문제의 예를 제공할 때, 새로운 이름을 만들어 내기보다는 실제 상황에 존재하는 테이블 이름, 변수 이름 등을 사용하는 편이 더 좋습니다. 문제는 테이블이나 변수의 이름과 관련 있을 수 있습니다. 이런 경우는 드물긴 하지만, 조심해서 나쁠 것은 없습니다.
결국 실제 상황을 사용하는 예를 제공하는 편이 당신에게도 더 쉬울 것이며, 우리에게도 훨씬 더 좋습니다. bug report에서 다른 사람들이 볼 수 없게 하고 싶은 데이터가 있다면, 앞에서 설명한 대로 Files 탭을 사용해 업로드할 수 있습니다. 정보가 정말로 극비이며 우리에게조차 보여주고 싶지 않다면, 다른 이름을 사용한 예를 제공해도 되지만, 이를 최후의 수단으로 간주해 주십시오.
Perl이나 PHP 같은 언어로 작성된 프로그램이 문제에 관련된 경우, 언어 처리기의 버전 번호와 함께 프로그램이 사용하는 모듈 버전도 포함하십시오. 예를 들어 DBI와
DBD::mysql 모듈을 사용하는 Perl 스크립트가 있는 경우, Perl, DBI, DBD::mysql의 버전 번호를 포함하십시오.
질문이 권한 시스템과 관련되어 있다면, mysqladmin reload의 출력과 연결을 시도할 때 발생하는 모든 오류 메시지를 포함하십시오. 권한을 테스트할 때는, mysqladmin reload version을 실행하고 문제가 발생하는 프로그램으로 접속을 시도해야 합니다.
bug에 대한 패치가 있다면 반드시 포함하십시오. 하지만 패치만 있으면 충분하거나, 테스트 케이스 등 패치가 수정하는 bug를 보여 주는 데 필요한 정보를 제공하지 않아도 우리가 패치를 사용할 수 있다고 가정하지 마십시오. 패치에서 문제를 발견하거나, 패치를 전혀 이해하지 못할 수도 있습니다. 이런 경우, 우리는 패치를 사용할 수 없습니다.
패치의 정확한 목적을 검증할 수 없다면, 패치는 사용되지 않습니다. 테스트 케이스는 이 점에서 도움이 됩니다. 패치가 발생 가능한 모든 상황을 처리한다는 점을 보여 주십시오. (드물게 발생하더라도) 패치가 동작하지 않는 경계 사례를 찾게 된다면 패치는 쓸모없을 수 있습니다.
bug가 무엇인지, 왜 발생하는지, 무엇에 의존하는지에 대한 추측은 대부분 틀립니다. MySQL 팀조차도 디버거를 사용해 bug의 실제 원인을 먼저 찾지 않는 이상 이런 것들을 추측할 수 없습니다.
bug report에서 레퍼런스 매뉴얼과 메일 아카이브를 확인했음을 명시하여, 스스로 문제를 해결하려고 시도했음을 다른 사람들이 알 수 있게 하십시오.
데이터가 손상된 것처럼 보이거나 특정 테이블에 접근할 때 오류가 발생한다면, 먼저
CHECK TABLE로 테이블을 확인하십시오. 이 문이 어떤 오류라도 보고한다면:
InnoDB 크래시 복구 메커니즘은 server가 kill된 후 재시작될 때 정리를 처리하므로, 일반적인 동작에서는 테이블을 “수리”할 필요가 없습니다. InnoDB 테이블에서 오류가 발생하면, server를 재시작하고 문제가 계속되는지, 아니면 오류가 메모리에 캐시된 데이터에만 영향을 미쳤는지를 확인하십시오. 디스크 상의 데이터가 손상된 경우, 영향을 받는 테이블을 덤프할 수 있도록
innodb_force_recovery
옵션을 활성화하여 재시작하는 것을 고려하십시오.
비트랜잭션 테이블의 경우,
REPAIR TABLE이나
myisamchk로 테이블을 수리해 보십시오.
Chapter 7, MySQL Server Administration을 참조하십시오.
Windows를 사용 중이라면,
lower_case_table_names의 값을 SHOW VARIABLES LIKE 'lower_case_table_names' 문으로 확인하십시오. 이 변수는 server가 데이터베이스 및 테이블 이름의 대소문자를 처리하는 방식에 영향을 줍니다. 각 값에 따른 동작은
Section 11.2.3, “Identifier Case Sensitivity”에 설명된 것과 같아야 합니다.
테이블이 자주 손상된다면, 언제, 왜 이런 일이 발생하는지 알아내야 합니다. 이 경우 MySQL 데이터 디렉터리의 오류 로그에 무엇이 일어났는지에 대한 정보가 들어 있을 수 있습니다(파일 이름에 .err 접미사가 있는 파일).
Section 7.4.2, “The Error Log”를 참조하십시오. bug report에 이 파일에서 관련 있는 정보를 포함해 주십시오. 일반적으로, 중간에 누군가가 업데이트를 kill하지 않는 이상
mysqld가 테이블을 손상시키는 일은 절대 없어야 합니다.
mysqld가 죽는 원인을 찾을 수 있다면, 우리가 문제에 대한 수정본을 제공하기가 훨씬 더 쉬워집니다.
Section B.3.1, “How to Determine What Is Causing a Problem”을 참조하십시오.
가능하다면 최신 버전의 MySQL Server를 다운로드하여 설치하고, 문제가 해결되는지 확인하십시오. 모든 MySQL 소프트웨어 버전은 철저히 테스트되었으며 문제 없이 동작해야 합니다. 우리는 가능한 한 모든 것을 하위 호환되도록 유지하는 것을 중요하게 여기며, MySQL 버전을 어려움 없이 전환할 수 있어야 합니다. Section 2.1.2, “Which MySQL Version and Distribution to Install”을 참조하십시오.
1.5 Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 9.5
1.7 MySQL Standards Compliance