mysql 에서 인코딩 및 migration 때 고려사항

How to successfully migration mysql v.3x to v.5.x

mysql 에서 글자셋은 3~4가지 영역에서 영향을 줄 수 있는데요,

1. mysql DB service daemon 시작때 옵션으로 지정해 '전체 서비스 영역'으로 강제하는 방법
(직접 소스 컴파일 설치했을 경우 character set 이 불분명한 경우도 있음)
  : daemon, log, service check, --with option, configure  ..

2. mysql.cnf 혹은 my.cnf 에서 'daemon 영역', 'client 영역'에서 charset,
   init_connect=set 으로 collation 지정하는 방법,
  : check System configuration file

3. db 와 table 에서 생성시 지정하는 방법(관리자, 사용자지정) 이 있습니다.
  : show variables like 'c%';
  : ...

4. 글자셋과 관련해 Service 와 Client가 자동설정 (예를들면 auto handshake) 하거나
   혹은 하지못하게 강제하는 방법이 있는데, 이는 연결 클라이언트에세 초기 연결시
   SET collation, SET NAMES 같은 방법으로 지정하고 이후 작업을 수행하는
   상황입니다.
  : php, asp, c, find & grep with 'SET keyword'

문제는, mysql v.3x -> v5.x 로 가면서 3가지 영역에서 많은 부분이 add & depricate
됐고, 각각의 사용자 DB/Table 또한 생성때 개별 설정이 가능하기 때문에 다중사용자
환경에서 일치하지 않는-깨지는 현상은 당연한 상황입니다.

굳이 분리한다면, 1은 Engineer, 2는 Admin, 3은 User, 4는 Programmer 에서 영역에
분산된 것으로, 각각에서 charset 관련된 걸 나열하고 해당 mysql 버전과 호환이
되는지 확인하면 됩니다.

이후에, backup & restore dump 때 호환이 가능하도록 글자셋 변경을 지정하여
수행하면 되고, 만약 두 버전간 dump된 파일에서 변환을 수행할 수 없다면, iconv
같은 변경을 해줘야 합니다.  또한 일부 애플리케이션에서는 글자셋을 수동으로
지정한 경우가 많은데, 이럴 경우 해당 프로그램 또한 검토해야 합니다.


사족으로 말씀드리면, mysql 에서 Enterprise Edition 영역을 둬서, 소스보다는
'서비스 영역'으로 Enterprise 환경에서 System Integration 을 따로 지원케
했는데요, 이런 추세에 영향을 받아 Postgres 에서 v8,v9에서 Enterprise 를
도입했죠. 흔히 말하는 '적정기술수준'에서 mysql 이 postgresql 를 각성시킨게 아마
이부분일 겁니다.