Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.22 Troubleshooting Problems Connecting to MySQL의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
MySQL 서버에 연결을 시도할 때 문제가 발생한다면, 아래 항목들은 문제를 해결하기 위해 수행할 수 있는 조치들을 설명합니다.
1$> mysql 2ERROR 2003: Can't connect to MySQL server on 'host_name' (111) 3$> mysql 4ERROR 2002: Can't connect to local MySQL server through socket 5'/tmp/mysql.sock' (111)
--port 옵션을 지정하거나, 올바른 네임드 파이프 또는 Unix 소켓 파일을 지정하기 위해 --socket 옵션을 지정하십시오. 소켓 파일의 위치를 찾으려면 다음 명령을 사용할 수 있습니다:1$> netstat -ln | grep mysql
서버가 네트워크 연결을 무시하도록 설정되어 있지 않은지, 또는 (원격으로 연결을 시도하는 경우) 네트워크 인터페이스에서 로컬에서만 리슨 하도록 설정되어 있지 않은지 확인하십시오. 서버가 skip_networking 시스템 변수를 활성화한 상태로 시작되었다면, TCP/IP 연결은 허용되지 않습니다. 서버가 bind_address 시스템 변수를 127.0.0.1로 설정한 상태로 시작되었다면, 루프백 인터페이스에서 로컬로만 TCP/IP 연결을 리슨 하며 원격 연결은 허용하지 않습니다.
MySQL에 대한 액세스를 차단하는 방화벽이 없는지 확인하십시오. 방화벽은 실행 중인 애플리케이션 기준이거나, MySQL이 통신에 사용하는 포트 번호(기본값은 3306) 기준으로 설정되어 있을 수 있습니다. Linux 또는 Unix에서는, 포트가 차단되지 않았는지 확인하기 위해 IP 테이블(또는 유사한 것) 설정을 확인하십시오. Windows에서는 ZoneAlarm 또는 Windows Firewall 같은 애플리케이션을 MySQL 포트를 차단하지 않도록 설정해야 할 수 있습니다.
그랜트 테이블이 액세스 제어에 사용될 수 있도록 올바르게 설정되어 있어야 합니다. 일부 배포 유형(예: Windows의 바이너리 배포, 또는 Linux의 RPM 및 DEB 배포)에서는, 설치 과정에서 그랜트 테이블이 포함된 mysql 시스템 데이터베이스를 포함하여 MySQL 데이터 디렉터리를 초기화합니다. 이를 수행하지 않는 배포의 경우, 데이터 디렉터리를 수동으로 초기화해야 합니다. 자세한 내용은 Section 2.9, “Postinstallation Setup and Testing”을 참조하십시오.
그랜트 테이블을 초기화해야 하는지 확인하려면, 데이터 디렉터리 아래에 mysql 디렉터리가 있는지 찾으십시오. (데이터 디렉터리는 일반적으로 data 또는 var라는 이름이며 MySQL 설치 디렉터리 아래에 위치합니다.) mysql 데이터베이스 디렉터리에 user.MYD라는 파일이 있는지 확인하십시오. 없다면, 데이터 디렉터리를 초기화하십시오. 그런 다음 서버를 시작한 후, 서버에 연결할 수 있어야 합니다.
root로 서버에 로그인하려고 하면 다음과 같은 에러 메시지를 받을 수 있습니다.1$> mysql -u root 2ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
이는 설치 중에 루트 비밀번호가 이미 할당되어 있으며 이를 제공해야 함을 의미합니다. 비밀번호가 어떤 방식으로 할당되었는지와, 일부 경우에는 이를 찾는 방법에 대해서는 Section 2.9.4, “Securing the Initial MySQL Account”를 참조하십시오. 루트 비밀번호를 재설정해야 하는 경우, Section B.3.3.2, “How to Reset the Root Password”의 지침을 참조하십시오. 비밀번호를 찾았거나 재설정한 후에는 --password (또는 -p) 옵션을 사용하여 root로 다시 로그인하십시오:
1$> mysql -u root -p 2Enter password:
그러나 mysqld --initialize-insecure를 사용하여 MySQL을 초기화한 경우에는 서버가 비밀번호 없이 root로 연결하는 것을 허용합니다(Section 2.9.1, “Initializing the Data Directory” 참조). 이는 보안상 위험하므로, root 계정에 비밀번호를 설정해야 합니다. 지침은 Section 2.9.4, “Securing the Initial MySQL Account”를 참조하십시오.
기존 MySQL 설치를 새로운 버전으로 업데이트했다면, MySQL 업그레이드 절차를 수행했습니까? 수행하지 않았다면, 수행하십시오. 그랜트 테이블의 구조는 새로운 기능이 추가될 때 때때로 변경되므로, 업그레이드 후에는 항상 테이블이 최신 구조를 가지는지 확인해야 합니다. 지침은 Chapter 3, Upgrading MySQL을 참조하십시오.
클라이언트 프로그램이 서버에 연결을 시도할 때 다음과 같은 에러 메시지를 받는다면, 이는 서버가 클라이언트가 생성할 수 있는 형식보다 새로운 형식의 비밀번호를 기대한다는 의미입니다:
1$> mysql 2Client does not support authentication protocol requested 3by server; consider upgrading MySQL client
Access denied를 받는다면, 어떤 옵션 파일에 예전 비밀번호를 지정해 두지 않았는지 확인하십시오.클라이언트 프로그램이 옵션 파일 사용을 억제하도록 하려면 --no-defaults 옵션을 지정하여 실행하십시오. 예:
1$> mysqladmin --no-defaults -u root version
클라이언트가 사용하는 옵션 파일 목록은 Section 6.2.2.2, “Using Option Files”에 나와 있습니다. 환경 변수는 Section 6.9, “Environment Variables”에 나와 있습니다.
root 비밀번호를 사용하고 있다는 의미입니다:1$> mysqladmin -u root -pxxxx ver 2Access denied for user 'root'@'localhost' (using password: YES)
위 에러가 비밀번호를 지정하지 않았을 때조차 발생한다면, 어떤 옵션 파일에 잘못된 비밀번호가 지정되어 있다는 의미입니다. 앞 항목에서 설명한 대로 --no-defaults 옵션을 사용해 보십시오.
비밀번호 변경에 대한 정보는 Section 8.2.14, “Assigning Account Passwords”를 참조하십시오.
root 비밀번호를 잃어버렸거나 잊어버린 경우, Section B.3.3.2, “How to Reset the Root Password”를 참조하십시오.
localhost는 로컬 호스트 이름의 동의어이며, 또한 호스트를 명시하지 않았을 때 클라이언트가 연결을 시도하는 기본 호스트이기도 합니다.--host=127.0.0.1 옵션을 사용하여 서버 호스트를 명시적으로 지정할 수 있습니다. 이는 로컬 mysqld 서버에 대한 TCP/IP 연결을 생성합니다. 또한 로컬 호스트의 실제 호스트 이름을 사용하는 --host 옵션을 지정하여 TCP/IP를 사용할 수도 있습니다. 이 경우, 클라이언트 프로그램이 서버와 동일한 호스트에서 실행되더라도, 해당 호스트 이름이 서버 호스트의 user 테이블 행에 지정되어 있어야 합니다.
Access denied 에러 메시지는 어떤 사용자로 로그인하려 했는지, 어떤 클라이언트 호스트에서 연결을 시도했는지, 그리고 비밀번호를 사용했는지를 알려줍니다. 일반적으로, 에러 메시지에 나타난 호스트 이름과 사용자 이름과 정확히 일치하는 한 행이 user 테이블에 있어야 합니다. 예를 들어, 에러 메시지에 using password: NO가 포함되어 있다면, 비밀번호 없이 로그인하려 했다는 의미입니다.
mysql -u user_name으로 데이터베이스에 연결하려 할 때 Access denied 에러를 받는다면, user 테이블에 문제가 있을 수 있습니다. 이를 확인하려면 mysql -u root mysql을 실행한 다음 아래 SQL 문을 실행하십시오:
1SELECT * FROM user;
결과에는 Host와 User 컬럼이 클라이언트의 호스트 이름과 MySQL 사용자 이름과 일치하는 행이 포함되어야 합니다.
Host 값을 가진 행이 user 테이블에 없다는 의미입니다:1Host ... is not allowed to connect to this MySQL server
이 경우, 연결 시 사용 중인 클라이언트 호스트 이름과 사용자 이름 조합에 대해 계정을 설정하면 문제를 해결할 수 있습니다.
연결 중인 머신의 IP 주소나 호스트 이름을 모르는 경우, user 테이블에 Host 컬럼 값이 '%'인 행을 추가해야 합니다. 그런 다음 클라이언트 머신에서 연결을 시도한 후, 실제로 어떻게 연결되었는지 확인하기 위해 SELECT USER() 쿼리를 사용하십시오. 그런 다음 로그에 나타나는 실제 호스트 이름으로 user 테이블 행의 '%'를 변경하십시오. 그렇지 않으면, 해당 사용자 이름에 대해 어떤 호스트에서든 연결을 허용하게 되어 시스템이 인시큐어한 상태로 남게 됩니다.
Linux에서는, 이 에러가 발생하는 또 다른 이유는 사용 중인 glibc 라이브러리의 버전과 다른 버전으로 컴파일된 바이너리 MySQL 버전을 사용하고 있기 때문일 수 있습니다. 이 경우, 운영 체제나 glibc를 업그레이드하거나, 해당 MySQL 버전의 소스 배포를 다운로드하여 직접 컴파일해야 합니다. 일반적으로 소스 RPM은 컴파일 및 설치가 매우 간단하므로 큰 문제는 아닙니다.
1$> mysqladmin -u root -pxxxx -h some_hostname ver 2Access denied for user 'root'@'' (using password: YES)
root로 연결을 시도할 때 다음 에러를 받는다면, user 테이블에 User 컬럼 값이 'root'인 행이 없고, mysqld가 클라이언트의 호스트 이름을 리졸브할 수 없다는 의미입니다:
1Access denied for user ''@'unknown'
이러한 에러는 DNS 문제를 나타냅니다. 이를 수정하려면, 내부 DNS 호스트 캐시를 재설정하기 위해 mysqladmin flush-hosts를 실행하십시오. Section 7.1.12.3, “DNS Lookups and the Host Cache”를 참조하십시오.
영구적인 해결책으로는 다음과 같은 것들이 있습니다:
DNS 서버에 어떤 문제가 있는지 파악하고 수정합니다.
MySQL 그랜트 테이블에 호스트 이름 대신 IP 주소를 지정합니다.
Unix에서는 /etc/hosts에, Windows에서는 \windows\hosts에 클라이언트 머신 이름에 대한 엔트리를 추가합니다.
skip_name_resolve 시스템 변수를 활성화하여 mysqld를 시작합니다.
--host-cache-size=0를 사용하여 mysqld를 시작합니다.
Unix에서 서버와 클라이언트를 같은 머신에서 실행하는 경우, localhost로 연결합니다. localhost에 대한 연결의 경우, MySQL 프로그램은 클라이언트에 TCP/IP 연결을 강제하는 연결 매개변수가 지정되지 않는 한 Unix 소켓 파일을 사용하여 로컬 서버에 연결을 시도합니다. 자세한 내용은 Section 6.2.4, “Connecting to the MySQL Server Using Command Options”를 참조하십시오.
Windows에서 서버와 클라이언트를 같은 머신에서 실행하고 서버가 네임드 파이프 연결을 지원하는 경우, 호스트 이름으로 .(period)를 사용하여 연결합니다. .에 대한 연결은 TCP/IP가 아닌 네임드 파이프를 사용합니다.
mysql -u root는 동작하지만 mysql -h your_hostname -u root는 Access denied를 반환한다면(_your_hostname_은 로컬 호스트의 실제 호스트 이름), user 테이블에 호스트 이름이 올바르게 지정되어 있지 않을 수 있습니다. 여기서 흔한 문제는 user 테이블 행의 Host 값이 언퀄리파이드 호스트 이름을 지정하고 있지만, 시스템의 이름 리졸루션 루틴이 풀리 퀄리파이드 도메인 이름(또는 그 반대)을 반환하는 경우입니다. 예를 들어, user 테이블에 호스트가 'pluto'인 행이 있지만 DNS가 MySQL에 호스트 이름을 'pluto.example.com'으로 알려준다면, 해당 행은 동작하지 않습니다. 이 경우, 호스트의 IP 주소를 Host 컬럼 값으로 갖는 행을 user 테이블에 추가해 보십시오. (또는 Host 값에 와일드카드를 포함하는 행을 user 테이블에 추가할 수도 있습니다(예: 'pluto.%'). 그러나 %로 끝나는 Host 값의 사용은 인시큐어하므로 권장되지 않습니다!)
mysql -u user_name은 동작하지만 mysql -u user_name some_db는 동작하지 않는다면, _some_db_라는 이름의 데이터베이스에 대해 해당 사용자에게 액세스를 그랜트하지 않은 것입니다.
서버 호스트에서 실행했을 때 mysql -u user_name은 동작하지만, 원격 클라이언트 호스트에서 실행했을 때 mysql -h host_name -u user_name이 동작하지 않는다면, 해당 사용자 이름에 대해 원격 호스트에서 서버 액세스를 허용하지 않은 것입니다.
왜 Access denied가 발생하는지 파악할 수 없다면, user 테이블에서 Host 값에 와일드카드('%' 또는 '_' 문자)를 포함하는 모든 행을 제거하십시오. 아주 흔한 에러는, 같은 머신에서 연결하기 위해 localhost를 지정할 수 있다고 생각하여 Host='%', User='some_user'인 새 행을 삽입하는 것입니다. 이것이 동작하지 않는 이유는, 기본 프리빌리지가 Host='localhost', User=''인 행을 포함되어 있기 때문입니다. 이 행은 Host 값이 '%'보다 더 구체적인 'localhost'를 가지므로, localhost에서 연결할 때 새 행보다 우선적으로 사용됩니다! 올바른 절차는, Host='localhost', User='some_user'인 두 번째 행을 삽입하거나, Host='localhost', User=''인 행을 삭제하는 것입니다. 행을 삭제한 후에는 그랜트 테이블을 다시 로드하기 위해 FLUSH PRIVILEGES 스테이트먼트를 반드시 실행해야 합니다. Section 8.2.6, “Access Control, Stage 1: Connection Verification”도 참조하십시오.
MySQL 서버에 연결할 수는 있지만, SELECT ... INTO OUTFILE 또는 LOAD DATA 스테이트먼트를 실행할 때마다 Access denied 메시지를 받는다면, user 테이블의 행에 FILE 프리빌리지가 활성화되어 있지 않은 것입니다.
그랜트 테이블을 직접 변경(예: INSERT, UPDATE, DELETE 스테이트먼트 사용)했는데 변경 사항이 무시되는 것처럼 보인다면, 프리빌리지 테이블을 서버가 다시 로드하도록 FLUSH PRIVILEGES 스테이트먼트 또는 mysqladmin flush-privileges 명령을 실행해야 한다는 점을 기억하십시오. 그렇지 않으면, 변경 사항은 다음에 서버가 재시작될 때까지 효과가 없습니다. UPDATE 스테이트먼트로 root 비밀번호를 변경한 후에는, 프리빌리지를 플러시할 때까지는 서버가 비밀번호가 변경된 사실을 알지 못하므로, 새 비밀번호를 지정할 필요가 없다는 점도 기억하십시오.
세션 도중에 프리빌리지가 변경된 것처럼 보인다면, MySQL 관리자가 프리빌리지를 변경했을 수 있습니다. 그랜트 테이블을 다시 로드하면 새로운 클라이언트 연결에 영향을 주지만, Section 8.2.13, “When Privilege Changes Take Effect”에 설명된 대로 기존 연결에도 영향을 줍니다.
Perl, PHP, Python, 또는 ODBC 프로그램에서 액세스 문제가 발생한다면, mysql -u user_name db_name 또는 mysql -u user_name -ppassword db_name을 사용하여 서버에 연결을 시도해 보십시오. mysql 클라이언트를 사용하여 연결할 수 있다면, 문제는 액세스 프리빌리지가 아니라 프로그램에 있습니다. (-p와 비밀번호 사이에 공백이 없으며, 비밀번호를 지정하기 위해 --password=password 구문을 사용할 수도 있습니다. -p 또는 --password 옵션을 비밀번호 값 없이 사용하면, MySQL이 비밀번호를 입력하라는 프롬프트를 표시합니다.)
테스트 목적으로, --skip-grant-tables 옵션을 사용하여 mysqld 서버를 시작하십시오. 그런 다음 MySQL 그랜트 테이블을 변경하고, SHOW GRANTS 스테이트먼트를 사용하여 변경 사항이 원하는 효과를 내는지 확인할 수 있습니다. 변경 사항에 만족하면, mysqladmin flush-privileges를 실행하여 mysqld 서버에 프리빌리지를 다시 로드하도록 지시하십시오. 이를 통해 서버를 중지하고 재시작하지 않고도 새로운 그랜트 테이블 내용을 사용하기 시작할 수 있습니다.
다른 모든 방법이 실패한다면, mysqld 서버를 (예: --debug=d,general,query)와 같은 디버깅 옵션과 함께 시작하십시오. 이는 시도된 연결에 대한 호스트 및 사용자 정보뿐만 아니라, 실행된 각 커맨드에 대한 정보를 출력합니다. Section 7.9.4, “The DBUG Package”를 참조하십시오.
MySQL 그랜트 테이블에 다른 문제가 있고 MySQL Community Slack에서 문의하는 경우에는, 항상 MySQL 그랜트 테이블의 덤프를 제공하십시오. mysqldump mysql 커맨드를 사용하여 테이블을 덤프할 수 있습니다. 버그 리포트를 제출하는 방법은 Section 1.6, “How to Report Bugs or Problems”의 지침을 참조하십시오. 일부 경우에는 mysqldump를 실행하기 위해 --skip-grant-tables과 함께 mysqld를 다시 시작해야 할 수 있습니다.
8.2.21 Setting Account Resource Limits
8.2.23 SQL-Based Account Activity Auditing