[태그:] mysql

Mac에서 MySQL 설치와 실행 그리고 몇가지 유의사항

불꽃남자 15 Comments

리눅스도 apt-get을 쓰느냐 yum을 쓰느냐에 따라서 지원하는 팩키지들이 조금씩 다른데 하물며 리눅스 서버에서만 놀다가 Mac에서 MySQL을 하려고하니 귀찮은게 한두가지가 아니다. 정리해보자.

MySQL 설치

설치는 간단하다. MySQL 홈페이지에서 .dmg 파일을 받아서 깔면 된다. 그런데 요세미티로 업그레이드 한 사람들은 그렇게 간단하진 않다! 일단 현재(2014.11월) MySQL 홈페이지에서 제공하는 설치파일이 10.9 버전까지만 있다. 나도 살짝 당황했다. 어랍쇼? 10.10이 없네? 요세미티에선 안되는건가? 혹시나 싶어 10.9 버전을 받아서 설치했더니… 뚜둥! 설치오류<img fetchpriority=” /> 그래서 나는 요세미티에선 MySQL 안깔린다! 라는 매우 성급한 결론을 내버렸다. 진짜 알깔리는건가? 설마~~ 그럴리가!! 그냥 10.8 버전 설치파일로 깔면 된다. ㅎㅎㅎ 뭐냐? -_-;;;;

이때 설치되는 경로는 아래와 같다.

$> cd /usr/local
$local> ls -al
....생략... mysql -> mysql-5.6.21-osx10.8-x86_64
....생략... mysql-5.6.21-osx10.8-x86_64

2015년 5월 덧, 주로 맥환경에서 개발하는 분들을 위해서 추천하는 방법은 위와 같은 방법 말고 그냥 HomeBrew를 설치해서 사용하기를 권장한다. 이번에 새로운 맥프레로 갈아타면서 패키지 관리를 이 HomeBrew를 이용해하고 있는데 너무 편하다. MySQL설치도 그냥 고민없이 아래명령어만 입력하면된다.

$> brew install mysql

혹시나 내가 이전에 설치했나? 궁금할때는 brew info 라는 명령어를 이용한다.

$> brew info mysql
mysql: stable 5.6.24 (bottled)
https://dev.mysql.com/doc/refman/5.6/en/
Conflicts with: mariadb, mysql-cluster, mysql-connector-c, percona-server
/usr/local/Cellar/mysql/5.6.23 (9687 files, 339M) *
Poured from bottle
.. 어쩌구 저쩌구 ...
server starting up correctly.

To connect:
    mysql -uroot

To have launchd start mysql at login:
    ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents
Then to load mysql now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
Or, if you don't want/need launchctl, you can just run:
    mysql.server start

이전에 HomeBrew로 설치한적이 있다면 위와 같은 정보를 확인할수있다. 나는 mysql을 미리 띄워놓지않고 필요할때만 서버를 띄워서 개발하는 편이라 mysql.server start 명령어를 애용하는 편이다. 아래에도 이어서 설명이 나오겠지만 HomeBrew의 강점중에 하나는 /usr/local/Cellar 폴더에 패키지를 설치한후 심볼릭 링크를 알아서 만들어주기 때문에 어디서든 명령어만 입력하면 된다. 즉 아래처럼 설치한 경로를 다 입력하지 않아도 되는 장점이 있다.

MySQL 서버 실행하기

리눅스에서 yum으로 mysql을 설치하면 아래와 같이 간단하게 실행할 수 있었다.

$> service mysqld start

하지만 맥은 리눅스가 아니다. 그래서 mysql.server 스크립트를 이용한다.

$> /usr/local/mysql/support-files/mysql.server
Usage: mysql.server  {start|stop|restart|reload|force-reload|status}  [ MySQL server options ]
$> sudo /usr/local/mysql/support-files/mysql.server start

MySQL 접속하기

서버를 실행했다면 이제 mysql 서버에 접속해보자. 보통은 커맨드라인 어디에서든 mysql로 로그인하면 된다. 하지만 그냥 로그인하면 권한이 없는 경우 많다. 그래서 일단 root로 로그인하자. 맥에 처음 mysql을 깔았다면 root는 비밀번호 없이도 로컬에서 접속이 가능할 것이다.

$> mysql -u root  // -uroot 라고 붙여서도 된다.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 528
Server version: 5.6.21 MySQL Community Server (GPL)
... 중략 ...
sql>

위와 같이 나온다면 일단 접속은 성공한거다!

사용할 DB 만들기

이제 개발에 필요한 혹은 사용할 데이터베이스를 만들어보자.

mysql> create database testdb;
Query OK, 1 row affected (0.00 sec)

그리고 꼭 캐릭터셋을 확인해야한다. mysql을 설치하고 따로 캐릭터셋(charset)을 따로 설정하지 않았다면 latin1 으로 설정되는데 latin1 캐릭터셋을 쓰면 한글은 당연히 안되고 몇몇 특수문자를 사용할경우 DB에서 입력이 안되는 경우가 허다하다. 그래서 반드시 utf-8로 설정되어 있는지 확인해야한다. 확인하는 방법은 다음과 같다.

mysql> show create database testdb;
+----------+-------------------------------------------------------------------+
| Database | Create Database                                                   |
+----------+-------------------------------------------------------------------+
| testdb   | CREATE DATABASE `testdb` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------+-------------------------------------------------------------------+
1 row in set (0.00 sec)

젠장 역시나,..-_-;;; latin1으로 되어 있다. 일단 만든건 지우자.

mysql> drop database testdb;
Query OK, 0 rows affected (0.00 sec)

MySQL 기본 캐릭터셋 설정하기

MySQL에서 설정파일을 읽는 순서는 다음과 같다.

  • /etc/my.cnf
  • /etc/mysql/my.cnf
  • /usr/local/mysql/etc/my.cnf
  • ~/.my.cnf

일단 /etc/my.cnf 파일이 있는지 확인하고 없으면 /usr/local/mysql/support-files 폴더에서 my-default.cnf 파일을 복사해온다.

$> cp /usr/local/mysql/support-files/my-default.cnf /etc/my.cnf

그리고 /etc/my.cnf 파일에 다음 내용을 추가한다.

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

init_connect=SET collation_connection=utf8_general_ci
init_connect=SET NAMES utf8

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

이제 다시 서버를 재시작한다. sudo 권한이 없으면 sudo를 붙인다.

$> sudo /usr/local/mysql/support-files/mysql.server restart

DB 생성 및 생성된 DB 사용자 추가하기

이제 거의 다왔다. 앞에서 설정한 캐릭터셋이 잘 됐는지 일단 확인하자.

mysql> create database testdb;
Query OK, 1 row affected (0.00 sec)

mysql> show create database testdb;
+----------+------------------------------------------------------------------+
| Database | Create Database                                                  |
+----------+------------------------------------------------------------------+
| testdb   | CREATE DATABASE `testdb` /*!40100 DEFAULT CHARACTER SET utf-8 */ |
+----------+------------------------------------------------------------------+
1 row in set (0.00 sec)

오예! 잘 됐다. 이제 권한을 추가하자. 권한을 추가하는 방법은 여러가지가 있지만 그냥 쉬운 grant 명령을 이용하자.

// localhost로 접속만 허용하는 dev 유저 계정 생성
mysql> grant all privileges on testdb.* to dev@localhost identified by 'password123';

// 원격 접속도 허용하는 devmaeul 유저 계정 생성 
mysql> grant all privileges on testdb.* to dev@'%' identified by 'password123';

dev라는 계정을 만들고 이 계정으로 사용할 testdb도 지정해줬으므로 이제 root가 아닌 dev 계정으로 로그인해서 사용할수있는 DB가 보이는지 확인해보자.

$> mysql -u dev -p
Enter password: (앞에서 지정한 패스워드 입력)
... 중략 ...
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| testdb             |
+--------------------+
3 rows in set (0.00 sec)

오예!~ testdb가 보인다! 여기까지 mysql로 개발할때 필요한 기본적인 과정이다.

타임존 설정 (업데이트 2015-08-31)

지금까지 기본적인 설정이 끝나서 문제가 없겠구나 했는데 개발하다보니 하나더 발견했다. 바로 타임존이다. 서버에 시간을 기록하는 상황이 아니면 잘 모르기 때문에 사전에 점검하지 않으면 나중에 운영하다 발견하게 된다. 실제로 최근 2달사이 이 문제를 두번 겪었다. 즉, 타임존 설정을 신경써두지 않으면 한국시간으로 오전 10시에 기록을 했는데 서버는 오전 1시로 인식하고 기록하게 된다는 얘기다. 보통 이 문제를 어떻게 해결하는지는 나는 모르겠다. 그냥 상식적으로 생각해보면 글로벌 서비스라면 UTC로 저장하고 한국에서만 서비스할 생각이라면 한국시간에 맞게 저장하는게 좋지않을까? 라고 단순하게만 생각했다. 하지만 그리 단순한 문제는 아니다. 이 얘기 좀금 있다가 다시하고, 여튼 신경쓰지 않았을때 기본값이 어떻게 들어가 있는지 잘 모르기 때문에 일단 현재 시간이 어떻게 저장되어 있는지부터 확인할 필요가 있다!

$> mysql -uroot
mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2015-08-31 02:52:24 |
+---------------------+
1 row in set (0.00 sec)

헐퀴! 현재 한국시간은 오전 11시 52분인데 서버는 새벽 2시란다. UTC로 설정되어 있다. 이번엔 내 로컬PC를 확인해봤다. 헐퀴! 이녀석은 또 제대로 나온다. 아~~ 이게 뭐지? 왜 다른거지? 둘다 특별히 설정한건 없는데,… 라는 생각이 들어서 MySQL 공식 문서를 찾아봤다. 에헤라~ 디야~ 그랬쿠나!! OS의 시간을 그대로 가져온다는구나야~~ http://dev.mysql.com/doc/refman/5.6/en/time-zone-support.html

그래서 현재 내PC와 운영중인 AWS 서버의 시간을 확인해봤다.

$ AWS> date
2015. 08. 31. (월) 03:06:53 UTC

$ local> date
2015년 8월 31일 월요일 12시 06분 35초 KST

자, 여기서 문제가 발생한다. MYSQL은 기본적으로 OS의 서버 시간을 가지고 설정하기 때문에 단순히 글로벌 서비스라서 UTC로 저장하고 국내용 서비스라서 KST로 저장하면 안되는거다. 왜냐면 서버시간을 물고 들어가기 때문에 서버 위에서 돌아가는 모든 어플리케이션도 영향을 받는다. 따라서 서버시간은 그냥 통일해야하는 문제가 먼저인 것이다. 나는 일단 지금 한국에서 개발하니까 한국시간을 기준으로 설정해야겠다.

그럼 타임존 설정은 어떻게 해야지? 간단하다. /etc/localtime 이라는 파일이 있는데 이 파일 설정을 한국시간으로 바꿔주면 된다. 아래와 같이 심볼릭 링크를 걸어주자!

$> ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime
$> ls -al | grep /etc/locatime
lrwxrwxrwx  1 root root      30  8월 31 12:17 localtime -> /usr/share/zoneinfo/Asia/Seoul
$> date
2015. 08. 31. (월) 12:18:08 KST

끝~

덧,

도움이 되셨나요? 그럼 광고 한번 클릭!

Spring Framework 에서 UTF-8 한글 설정

불꽃남자 Leave a comment

인코딩 문제로 오늘 또 하루종일 씨름했다.

사실 그닥 어려운게 아닌데.. 처음 설정을 잘못해놓으면,.
고생하기 쉽상이다.
웹개발에서 인코딩과 관련해서 신경써야할 부분
아래와 같은 3가지라고 보면 되겠다.
1. 클라이언트 (javascript)
2. 서버 (apache or tomcat 설정)
3. DB
1. DB 캐릭터셋 설정하기
그중에서 가장 실수하기 쉬운 것중에 하나는 DB 설정.
mysql 을 설치하고, 꼭 아래와 같은 명령어로 현재 mysql 의 설정 상태를 확인해야한다.

mysql> \s

mysql 을 설치할대, 기본 캐릭터셋이 latin1 으로 설정되어 있기때문에
신경써서 설치하지 않으면, 원하는 utf8 설정이 안된다.
설정이 제대로 안되어 있다면, 설치 폴더로 가서 my.ini 파일을 열어
인코딩 관련 부분을 모두 수정해줘야한다.
여기서 그렇게 했는데도 불구하고, \s 명령어를 이용해, mysql 설정상태를 확인 했을때,
DB character set 이 latin1 로 나오는 경우가 있는데..
이런 경우는, create database로 db를 생성할 당시의 캐릭터 셋이 latin1이 었기 때문에
뒤늦게 수정해봐야 수정되지 않는다. 결국엔 db를 날리고 다시 생성해야한다.
이런 경우 때문에 초기 설치시에 주의해서 원하는 캐릭터셋으로 설정을 해야한다.
2. 스프링 프레임웍에서 설정하기

두번째로 서버 설정을 확인해야하는데.. tomcat에서 server.xml 을 열어서 8080포트와 8009번 포트의
커넥터에 URIEncoding=“UTF-8” 를 추가해준다.
스프링 프레임웍을 이용할경우, web.xml 열어서 아래와 같은 필터를 추가해준다.

<filter>

<filter-name>encodingFilter</filter-name>

<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>

<init-param>

<param-name>encoding</param-name>

<param-value>UTF-8</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>encodingFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

그리고 xxxx-servlet.xml 파일을 열어서, viewResolver를 아래와 같이 또 수정해준다.

<bean id=“viewResolver” class=“org.springframework.web.servlet.view.InternalResourceViewResolver”>

<property name=“prefix” value=“/WEB-INF/view/”/>

<property name=“suffix” value=“.jsp” />

<property name=“contentType” value=“text/html; charset=UTF-8”/>

</bean>

이렇게 해주면, 기본적으로 클라이언트딴에서 특별한 인코딩을 수행하지 않아도 UTF8로 인식을 한다.
때문에 응답할때도 특별한 디코딩을 해주지 않아도 된다.


3. 서버 설정없이 클라이언트에서 무조건 UTF-8로 넘겨주기

위와 같이 서버딴에서 특별한 설정을 해주지 않았다면,
다소 귀찮은 작업을 해줘야하는데..
그것은 클라이언트에서 서버로 정보를 날릴때, 무조건 인코딩을 해서 넘겨야 한다는 것이다.
인코딩하는 방법은 간단하다.
아래와 같이 자바스크립트를 이용해, 넘기고자 하는 정보를 encodeURIComponent()
함수를 이용해 인코딩 해주면, 넘기는 정보를 UTF-8로 인코딩해서 넘기게 된다.
4. 인코딩 파헤치기

보통은 클라이언트에서 서버로 요청 파라메터 정보를 넘기게 되면,
아래와 같은 3가지 인코딩 방식으로 넘기게 된다. 아래 1번을 제외한 나머지 방법은
브라우저가 설정된 인코딩 방식을 따르게 된다. 1번방법은 자바스크립트에서 강제로 인코딩한다.
예를 들어 “한글”이란 문자열을 넘기면,
1. encodeURIComponent() 로 인코딩 할때, “%25ED%2595%259C%25EA%25B8%2580“
2. UTF8 인코딩을 할때,  “%ED%95%9C%EA%B8%80”
3. EUC-KR로 넘길 때, “%C7%D1%B1%DB“

위 3가지 타입을 UTF8로 설정된 서블릿에서 각각 request.getParameter() 로 넘겨받은 정보를 읽어오게 되면,
UTF8로 디코딩 되어 각각  
1. “%ED%95%9C%EA%B8%80“
2. “한글“
3. “???”
로 읽혀오게 된다.
여기서 문제는 3번이 문제가 된다. 3번은 실제로 “한글”이란 정보를 EUC-KR로 인코딩해서 넘기게 되는데..
서블릿에서 UTF-8로 디코딩을 하게 되어 알수없는 값이 되어버린다.

그리고 서버에서 이것을 다시 UTF8 캐릭터셋으로 설정된 DB에 그대로 저장하면,. 각각
1. “%ED%95%9C%EA%B8%80“
2. “?쒓?”
3. “ㅁ싼깍옙”
로 다시 저장된다.
1번을 제외한 2,3번 방식으로 DB에 저장이 되면, 본래 기대했던 값들과 다른 값들로 저장이 되는데..
DB 정보를 서블릿에서 다시 읽어볼때, 같은 UTF8로 디코딩을 하게 되면 사실 큰문제 없다.
하지만 위 DB정보를 다른 캐릭터셋으로 설정된 서블릿에서 읽어오게 되면 이식성에 문제가 생긴다.
또한 DB 캐릭터 셋이 UTF8이 아닌 다른 캐릭터셋으로 설정이 되었다면, DB에 저장될때 마찬가지로
문제가 생길수있다.

때문에 UTF8로 다국어를 지원해야하는 특별한 상황이라면, 1번 방법을 사용하는것이 보다 안전하다.
하지만 보통 하나의 캐릭터셋만을 지원하거나 통일하기 때문에 2번 방식으로 대부분 커버가 가능하다.

사실 더 중요한 것은, 인코딩과 디코딩할때,
클라이언트(브라우저인코딩) – 서버 – DB
3박자를 모두 잘 맞춰서 해줘야 한다는 것이다.

이상 정리 끝~

microtime 의 비밀, microtime을 로컬타임으로 변환하기.

불꽃남자 Leave a comment

오늘은 Microtime 에 대해서 이야기 해봐야겠당. 사실 나도 정확히 요놈에 대해 알지 못한다. 그런데 오늘 이놈 때문에 삽질을 한게 있어서 적고 넘어간다. 사실 내가 하고 싶었던건, zeroboard에서 reg_date로 들어가 있는 날짜를 jsp에서 불러와 출력하고 싶었다. 내가 검색 능력이 딸려서 못찾은건지, php에서는 기본 함수로 있는데.. jsp에서는 microtime을 현재 시간으로 변환해주는 메소드를 찾지 못했다.

여기저기 Q/A를 뒤져봤지만.. 못찾았다.. 그래서 그냥 나몰라라 접어두고 있었는데.. 오늘 마침 TDD(테스트 주도개발) 연습을 하면서 날짜를 컨트롤하는 예제를 뚝딱뚝딱 하고 있었다. 그래서 이왕 하는 김에 DateTime  클래스를 java로 구현해봤다. 이놈의 역할은 간단하다. microtime 을 인자로 받아서 현재시간으로 출력해주기위한 클래스다. 이것을 구현하기 위해 microtime을 다시 찾아봤다.

검색 결과에 의하면, microtime은 100/1 초까지 유닉스시간형태로 반환을 해준다고 한다. 기준은 1970년 1월 1일 0시 ㅇ분 00초를 부터 시작이다. 중요한건 1970년 1월 1일 0시 00분 00초가 기준이라는것이다. 아마도 1970년도가 유닉스 탄생해가 아닌가하는 추측해본다. 물론 찾아보지 않았다..귀찮아서..( 누군가 유닉스 탄생시기를 알려주겠지?~ ㅎㅎ)

다시 본론으로 돌아와서 zeroboard 의 reg_date는 mysql에 int(13)으로 잡혀있다. 실제로 값을 불러오면, 10자리 숫자가 나온다. 추측해보건데,.. 이 10자리 숫자를 환산하면, 0000년 00월 00일 00시 00분 00초로 나올것이다. 마침 32비트 컴퓨터의 int형 범위도 대략 10자리수가 나온다. 여기서 재밌는 사실을 알아냈다. microtime의 유효범위가 2037년쯤 된다고 한다. 만약에 2037년이 지나면, 이상해 진다고 하던데.. 아마도 그 이유는 int 범위에 굉장히 밀접한 관계가 있지 싶다.

시간을 계산해 보면,
1분은 60초,
1시간은 3600초,
하루는 86400초,
한달은 날짜마다 계산이 다르다.
단, 1년은 365일이고, 윤년일 경우 1년은 366일..
즉, 1년은 31536000초이고, 윤년인 해일 경우엔, 31622400초가 된다.

int의 최대범위는 2147483647 이고, 이것을 평년으로 나누면,..대략 68년이 나온다. 그러므로 1970년을 기준으로하면 2038년이 딱떨어진다. ㅋㅋㅋ 이것으로, 마이크로타임은 32비트 컴에서 내부적으로 int형 4바이트로 구현되어 있음을 짐작 할수있다. 이미 microtime을 로컬타임으로 변환하기 위한, 모든 아이디어는 앞에 서술한거 같다.

다시한번 짚어보면,
윤년을 계산해 내야하고,
날짜를 계산해 내기 위해, 달별로 일수를 짚어내야한다.
물론 윤년이 낀 해의 2월은 29일이다.
요 날짜만 구해낸다면, 시간은 식은죽먹기~!
시간구할때 한가지 더 생각해봐야할껀 로컬타임..
우리나라의 경우 +9 시간을 해야한다.

그밖에

TDD 연습을 위한 페이지