[MySQL] how to get table information

1. Table 목록 가져오기
SELECT table_name, table_rows, avg_row_length, table_collation
FROM information_schema.`TABLES` T
where table_schema = ‘테이블명’;

2. Table 정보 가져오기
SELECT column_name, column_default, is_nullable, data_type, character_maximum_length,
numeric_precision, numeric_scale, collation_name
FROM information_schema.`COLUMNS` C
where table_schema = ‘스키마명’
and table_name = ‘테이블명’
order by ordinal_position;

[MySQL] Access denied 에러 발생 원인

출처 : 링크

5.7.8. Access denied 에러 발생 원인

MySQL 서버에 접속을 시도할 때 문제가 발생한다면, 아래의 과정 중에 하나를 가지고 문제를 해결하도록 한다.
서버가 구동되고 있는지를 확인한다. 아래와 같은 에러가 나오는 원인 중의 하나는, 서버가 구동을 하고 있지 않는 것이다:
shell> mysql
ERROR 2003: Can’t connect to MySQL server on ‘host_name’ (111)
shell> mysql
ERROR 2002: Can’t connect to local MySQL server through socket
‘/tmp/mysql.sock’ (111)
서버는 구동을 하고 있다고 한다면, TCP/IP 포트, 네임드 파이프, 또는 유닉스 소켓 파일 등을 사용해서 서버에 접속을 다시 시도해 본다. 클라이언트 프로그램을 호출할 때 이 문제를 해결하기 위해서는, –port 옵션을 사용해서 포트 번호를 지정하거나, 또는 –socket 옵션을 사용해서 지명된 파이프 또는 유닉스 소켓 파일의 이름을 지정한다. 소켓 파일이 있는 곳을 알아내기 위해서 다음 명령어를 사용한다:
shell> netstat -ln | grep mysql
서버가 접근 제어를 올바르게 처리할 수 있도록 그랜트 테이블을 정확히 설정해야 한다. 몇몇 배포판의 경우 (윈도우상의 바이너리 배포판, 또는 리눅스의 RPM 등)에는, 설치 과정에서 그랜트 테이블을 가지고 있는 mysql 데이터 베이스를 초기화 시킨다. 이러한 일을 하지 못하는 배포판의 경우에는, mysql_install_db 스크립트를 사용해서 수동으로 그랜트 테이블을 초기화 해야 한다. Section 2.10.2, “유닉스 설치후 처리 프로세스”를 참조.
그랜트 테이블을 초기화 시켜야 할지를 판단할 수 있는 한 가지 방법은 데이터 디렉토리 밑에 있는 mysql 디렉토리를 검사하는 것이다. (데이터 디렉토리는 보통 data 또는 var라는 이름으로 되어 있고 MySQL 설치 디렉토리 아래에 있다.) mysql 데이터 디렉토리에 user.MYD라는 파일이 있는지 확인한다. 없다면, mysql_install_db 스크립트를 실행한다. 이 스크립트를 실행하고 서버를 재 시작한 다음에, 아래의 명령어를 실행해서 초기 권한을 테스트한다:
shell> mysql -u root test
이렇게 하면, 에러 없이 서버에 접속할 수 있게 된다.
MySQL 설치를 갱신한 후에는, 서버에 접속을 해서 사용자와 사용자들의 접근 퍼미션 (permission)을 설정한다:
shell> mysql -u root mysql
MySQL root 사용자는 초기에 패스워드를 가지고 있지 않기 때문에 서버에 곧장 연결을 할 수 있다. 그러나 보안 상 위험이 있기 때문에 반드시 Section 2.10.3, “초기 MySQL 계정 보안 처리”에서 설명하는 방식으로 계정에 보안 처리를 하도록 한다.
이미 설치되어 있는 MySQL을 새로운 버전으로 업그레이드를 하였다면, mysql_upgrade 스크립트를 다시 실행하였는가? 실행하지 않았다면, 실행하도록 한다. 그랜트 테이블의 구조는 새로운 기능이 추가되면 변경이 되기 때문에, 버전 업그레이드를 한 후에는 항상 테이블이 새로운 버전 구조를 가지고 있도록 만들어야 한다. 이렇게 하는 방법은 Section 5.5.7, “mysql_upgrade —MySQL 업그레이드를 위한 테이블 검사하기”를 참조하기 바란다.
클라이언트 프로그램이 서버에 접속을 할 때 아래와 같은 에러 메시지를 받게 된다면, 이것은 클라이언트가 만들어 내는 포맷이 아닌 새로운 포맷의 패스워드를 서버가 요청한다는 것을 의미하는 것이다:
shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client
이것을 처리하는 방법에 대해서는 Section 5.7.9, “MySQL 4.1 이후의 패스워드 해싱”을 참조하기 바란다.
root 사용자로 접속을 시도할 때 아래와 같은 에러를 받게 되면, 이것은 user 테이블에 ‘root’ 값 User 컬럼을 가지고 있는 열이 없고 mysqld가 클라이언트용 호스트 이름을 해석하지 못하고 있다는 것을 의미한다:

Access denied for user ''@'unknown' to database mysql
이와 같은 경우에는, –skip-grant-tables 옵션을 가지고 서버를 재 시작하고 /etc/hosts 파일 또는 \windows\hosts 파일을 편집해서 호스트 엔트리에 클라이언트 호스트를 추가하도록 한다.
클라이언트 프로그램은 옵션 파일 또는 환경 변수에서 지정하는 접속 파라미터를 사용한다는 것을 기억하기 바란다. 명령어 라인에서 접속 파라미터를 지정하지 않을 때 클라이언트 프로그램이 틀린 디폴트 접속 파라미터를 보낸다고 생각되면, 지정한 환경 변수와 적용 되는 옵션 파일을 검사하라. 예를 들면, 아무런 옵션 없이 클라이언트를 구동할 때 Access denied라는 에러를 받게 된다면, 옵션 파일들 안에 이전의 패스워드 타입을 지정했는지 확인한다!
클라이언트 프로그램을 호출할 때 –no-defaults 옵션을 사용해서 옵션 파일을 사용하지 못하도록 할 수 있다. 예를 들면:
shell> mysqladmin –no-defaults -u root version
클라이언트가 사용하는 옵션 파일 리스트는 Section 4.3.2, “옵션 파일 사용하기”에 나와 있으며, 환경 변수 리스트는 Section 2.14, “환경 변수”에 나와 있다.
아래와 같은 에러가 나온다면, 이것은 root 패스워드를 잘못 사용했다는 것을 의미한다:
shell> mysqladmin -u root -pxxxx ver
Access denied for user ‘root’@’localhost’ (using password: YES)
아무런 패스워드도 지정하지 않았는데 위와 같은 에러가 나온다면, 이것은 옵션 파일들 중 한 곳에 잘못된 패스워드를 넣었다는 것을 의미한다. 위에 나온 것을 가지고 –no-defaults 옵션을 사용해서 다시 한번 시도한다.
root 패스워드를 잊었다면, mysqld를 –skip-grant-tables 옵션으로 시작해서 패스워드를 변경하도록 한다.
SET PASSWORD, INSERT, 또는 UPDATE를 사용해서 패스워드를 변경한다면, 반드시 PASSWORD() 함수를 사용해서 패스워드를 암호화 해야 한다. PASSWORD()를 사용하지 않으면, 패스워드는 동작을 하지 않게 된다. 예를 들면, 아래의 명령문은 패스워드를 설정하기는 하지만, 암호화를 하지 못하기 때문에 사용자는 접속할 수 없게 된다:
SET PASSWORD FOR ‘abe’@’host_name’ = ‘eagle’;
대신에, 다음과 같이 패스워드를 설정한다:
SET PASSWORD FOR ‘abe’@’host_name’ = PASSWORD(‘eagle’);
GRANT 또는 CREATE USER 명령문, 또는 mysqladmin password 명령어를 사용해서 패스워드를 지정할 때에는 PASSWORD() 함수가 필요 없다. 이러한 것들은 자동으로 PASSWORD()를 사용해서 패스워드를 암호화 시킨다. Section 5.8.5, “계정 패스워드 할당하기”를 참조할 것.
localhost는 로컬 호스트 이름과 같은 것이며, 이것은 또한 호스트를 명확하게 지정하지 않을 경우에 클라이언트가 접속을 시도하는 디폴트 호스트가 된다.
mysql -u user_name을 사용해서 데이터베이스에 접속을 시도할 때 Access denied라는 에러가 생긴다면, 그 이유는 user 테이블에 문제가 있기 때문이다. mysql -u root mysql를 실행한 후에 아래의 SQL 명령문을 입력해서 이 테이블을 검사한다:
SELECT * FROM user;
이 명령문을 실행하면 시스템 호스트 이름과 MySQL 사용자 이름에 매치되는 Host 와 User 컬럼 열이 결과 값에 나오게 된다.
Access denied 에러는 어떤 사용자 이름으로 로그인을 시도하고 있는지, 어떤 클라이언트 호스트에서 접속을 하고자 하는지, 그리고 패스워드를 사용하고 있는지를 알려준다. 정상적인 경우라면, 에러 메시지에 나와 있는 호스트 이름과 사용자 이름에 정확히 매치되는 열을 user 테이블에 가지고 있어야 한다. 예를 들면, using password: NO가 포함된 에러 메시지를 받게 된다면, 이것은 패스워드 없이 로그인을 시도하였다는 것을 의미한다.
MySQL 서버가 구동되고 있는 서버가 아닌 다른 호스트에서 접속을 시도할 때 아래와 같은 에러가 발생한다면, 그것은 user 테이블에 클라이언트 호스트와 매치되는 Host 값 열이 존재하지 않는다는 것을 의미한다:
Host … is not allowed to connect to this MySQL server
접속을 시도할 때 클라이언트의 호스트 이름과 사용자 이름에 대한 계정을 설정해서 이 문제를 해결할 수 있다.
접속을 시도하는 시스템의 IP 번호 또는 호스트 이름을 모른다면, user 테이블의 Host 컬럼에 ‘%’를 넣는다. 클라이언트 머신에서 접속을 시도한 후에는, SELECT USER() 쿼리를 사용해서 실제로 접속을 했는지 확인한다. (그런 다음에 user 테이블 열의 ‘%’값을 로그에서 찾은 실제 호스트 이름으로 바꾼다. 그렇지 않으면, 서버는 모든 호스트가 접속을 할 수 있도록 허용을 하기 때문에 시스템 보안에 문제가 생기게 된다.)
리눅스에서 사용하는 버전과는 다른 glibc 라이브러리 버전을 사용해서 컴파일된 MySQL 바이너리 버전을 사용할 경우에도 위와 동일한 문제가 발생하기도 한다. 이와 같은 경우에는, OS 또는 glibc를 업그레이드 하거나, 또는 MySQL 소스 버전을 다운로드해서 스스로 컴파일한 후에 사용하도록 한다.
접속을 시도할 때 호스트 이름은 지정하였으나, 호스트 이름이 보이지 않고 IP 번호만 나오는 에러를 가지게 되면, 그것은 MySQL 서버가 IP 번호를 호스트 이름으로 해석할 때 에러가 발생했다는 것을 의미하는 것이다:
shell> mysqladmin -u root -pxxxx -h some_hostname ver
Access denied for user ‘root’@” (using password: YES)
이것은 DNS 문제를 가리키는 것이다. 이럴 경우에는 mysqladmin flush-hosts를 실행해서 내부 DNS 호스트 이름 캐시를 리셋 시킨다
몇 가지 영구적인 해결 방법은 다음과 같다:
DNS 서버 문제를 알아내서 고친다.
MySQL 그랜트 테이블에 호스트 이름이 아닌 IP 번호를 지정한다.
클라이언트 머신 이름 엔트리를 /etc/hosts 또는 \windows\hosts에 넣어 둔다.
mysqld를 –skip-name-resolve 옵션으로 구동시킨다.
mysqld를 –skip-host-cache 옵션과 함께 구동 시킨다.
유닉스 시스템의 경우, 서버와 클라이언트를 하나의 머신에서 구동시킨다면, localhost에 접속 하도록 한다. Localhost에 대한 유닉스 접속은 TCP/IP가 아닌 유닉스 소켓 파일을 사용한다.
윈도우 시스템의 경우, 서버와 클라이언트가 동일한 머신에서 구동이 되고, 서버가 지명된 파이프 접속을 지원 한다면, 호스트 이름 . (period)에 접속 하도록 한다. . 에 대한 접속은 TCP/IP가 아닌 지명된 파이프를 사용한다.
mysql -u root test가 동작은 하지만 mysql -h your_hostname -u root test로 인해 Access denied (your_hostname은 로컬 호스트의 실제 호스트 이름)가 발생한다면, 이것은 아마도 user 테이블에 정확한 호스트 이름을 가지고 있지 않기 때문일 것이다. 이것이 가지고 있는 일반적인 문제점은 바로, user 테이블 열에 있는 Host 값이 검증되지 않은 호스트 이름을 가리키고 있으나, 시스템 이름 해석 루틴은 완전히 검증된 도메인 이름을 돌려준다는 것이다 (혹은 그 반대). 예를 들면, user 테이블에 호스트 ‘tcx’ 엔트리가 있으나, DNS가 MySQL에게 호스트 이름은 ‘tcx.subnet.se’라고 알려준다면, 그 엔트리는 동작을 하지 않게 된다. Host 컬럼 값을 호스트의 IP 번호로 가지고 있는 user 테이블에 엔트리를 추가하도록 해본다. (다른 방법으로는, Host 값에 와일드 카드가 있는 user 테이블에 엔트리를 추가해 본다; 예를 들면, ‘tcx.%’. 하지만, ‘%’로 끝나는 이름을 사용하는 것은 보안에 문제가 생기기 때문에 권장하지는 않는다!)
mysql -u user_name test가 동작하기는 하지만 mysql -u user_name other_db_name 이 동작을 하지 않는다면, 이것은 지정한 사용자에게 other_db_name에 대한 데이터 베이스 접근 권한을 승인하지 않은 것이다.
mysql -u user_name가 서버 호스트에서 실행될 때에는 제대로 동작 하지만, 리모트 클라이언트 호스트에서 실행할 때에는 mysql -h host_name -u user_name가 동작하지 않는다면, 리모트 호스트에서 지정한 사용자 이름에 대해서 서버 접근을 활성화 시키지 않은 것이다.
Access denied 에러가 발생한 이유를 모른다면, 와일드 카드를 가지고 있는 모든 Host 엔트리를 (‘%’ 또는 ‘_’를 가지고 있는 엔트리)를 user 테이블에서 삭제를 하도록 한다. 가장 흔히 발생하는 에러는 Host=’%’ 와 User=’some_user’를 가지고 새로운 엔트리를 삽입하면, 동일 머신에서 접속 하기 위한 localhost지정이 가능하다고 생각하기 때문이다. 그러나 이렇게 지정하고 에러가 발생하는 이유는 디폴트 권한이 Host=’localhost’ 와 User=” 엔트리를 가지고 있기 때문이다. 엔트리는 ‘%’ 보다 구체적인 Host 값인 ‘localhost’를 가지고 있기 때문에, localhost에서 접속을 할 때 새로운 엔트리가 아닌 그것을 우선적으로 사용한다. 따라서, Host=’localhost’ 와 User=’some_user’를 사용해서 두 번째 엔트리를 삽입하거나, 또는 Host=’localhost’ 와 User=”를 가지고 있는 엔트리를 삭제하는 것이 올바른 처리 방법이다. 엔트리를 삭제한 후에는 그랜트 테이블을 다시 읽어 오기 위해 FLUSH PRIVILEGES 명령문을 입력하는 것을 잊지 말도록 한다.
아래의 에러가 발생한다면, 그것은 db 또는 host 테이블에 문제가 있기 때문일 것이다:
Access to database denied
db 테이블에서 선택된 엔트리가 Host 컬럼에 빈 값을 가지고 있다면, host 테이블에 db 테이블 엔트리를 적용하는 호스트 지정 엔트리가 하나 이상 존재하는지 확인한다.
MySQL 서버에 접속은 할 수 있지만, SELECT … INTO OUTFILE 또는 LOAD DATA INFILE 명령문을 입력할 때마다 Access denied 에러 메시지가 발생한다면, user 테이블 엔트리가 FILE 권한을 사용할 수 없기 때문이다.
직접 그랜트 테이블을 변경하였지만 변경된 내용이 무시된다고 판단되면, FLUSH PRIVILEGES 명령문 또는 mysqladmin flush-privileges 명령어를 실행 시켜서 서버가 권한 테이블을 다시 읽어 오도록 만들어야 한다. 그렇지 않으면, 서버가 재 구동되기까지 변경한 내용이 적용되지 않는다. UPDATE 명령어를 가지고 root 패스워드를 변경한 후에는 권한을 플러시하기 전까지 새로운 패스워드를 지정할 필요가 없는데, 그 이유는 서버가 변경된 패스워드를 아직 모르고 있기 때문이다!
권한이 세션 도중에 변경되었다고 판단되면, 그것은 관리자가 변경을 한 것으로 생각할 수 있다. 그랜트 테이블을 다시 읽어 오는 것은 새로운 접속에 적용되기도 하지만, Section 5.7.7, “권한 변경이 적용되는 시점”에서 설명하고 있는 것처럼 현재 존재하고 있는 접속에도 영향을 미치게 된다.
Perl, PHP, Python, 또는 ODBC 프로그램에 대한 접속에 문제가 있다면, mysql -u user_name db_name 또는 mysql -u user_name -pyour_pass db_name를 사용해서 서버에 접속해 보도록 한다. mysql 클라이언트를 사용해서 접속할 수 있다면, 문제는 접근 권한에 있는 것이 아니라 프로그램 자체에 있는 것이다.
테스트를 하기 위해서 mysqld 서버를 –skip-grant-tables 옵션과 함께 시작 해본다. 그런 다음 MySQL의 그랜트 테이블을 변경하고 mysqlaccess 스크립트를 사용해서 변경시킨 내용이 원하는 형태로 진행되는지를 검사한다. 변경 내용이 제대로 동작되면, mysqladmin flush-privileges를 실행해서 mysqld 서버가 새로운 그랜트 테이블을 사용해서 시작 하도록 만든다.
모든 것이 실패를 할 경우에는 디버깅 옵션을 사용해서 mysqld 서버를 구동 시켜본다 (예를 들면, –debug=d,general,query). 이렇게 하면, 접속을 시도한 호스트와 사용자에 대한 정보와 함께 입력된 각 명령어에 대한 정보도 보여 준다.

[iPhone] iPhone App 76 source, tutorial, link

http://xguru.net/622

출처 : http://www.raywenderlich.com/1948/how-integrate-itunes-file-sharing-with-your-ios-app

본 마음대로~ 의역했으며, 빠진부분 또는 잘못된 내용이 있을 수 있으니 원문을 참조바랍니다.

1. 앱과 아이튠스 간 파일 공유하기.
추천 링크 : http://www.raywenderlich.com/1948/how-integrate-itunes-file-sharing-with-your-ios-app

간단한 방법 : Info.plist안에 UIFileSharingEnabled 추가 후 체크.

[SVN] Tutorial

Eclipse Tip.

Team Synchronizing 문제 해결법

싱크 문제는 실제 서버와의 데이터 충돌로 인해 발생되고는 합니다.

리비전이 필요하지 않은 파일들은 싱크 파일목록에서 제거해주는게 개발하는데에 불편을 해소 할 수 있습니다.

패턴을 이용한 해결법

환경설정 > Team > Ignored Resoures 메뉴에서 파일 패턴을 이용하여 파일 싱크에서 제외 시킬 수 있습니다.

파일리스트 등록 해결법

프로젝트 리스트 > 해당 파일 위치에서 마우스 우 클릭을 하여 Team > Add to svn : ignore를 선택하여 파일 싱크 제외 항목을 등록합니다.