두달간 삽질끝에 MYSQL DB오류에 대해
안녕하세요.
필요에 의해서 MYSQL의 DB이전을 하게 되었습니다.
mysqldump로 기본값으로 떠와서 아무 설정 없이 넣었더니,
어랍쇼 글자가 ???? 으로 깨지네요.
UTF로 케릭셋을 설정해 뽑아 낸 후 집어넣으면 중복 에러가 납니다.
더군다가 케릭셋이 EUCKR도 아닙니다.
그래요 바이너리로 무식하게 뽑아서 바이너리로 넣어주니 글자는 잘 나와 주네요.
그런데 여기서 EUCKR엔 없는 CP949문자를 레코드에 넣어주면 그 뒤의 데이터를 싹 날려버립니다.
그 예로 '됬 셨 쫒 뷁' 등이 있는데요.
상황을 만들어 보자면
"참 잘 됐습니다"
경우에는 그냥 입력 되지만
"참 잘 됬습니다"
라고 입력하면 됬을 포함한 그 뒤의 글자들은 날아가버린채로
"참 잘 "
만 입력 됩니다.
옮기고자 하는 서버는 둘다 5.0버전대고, 다만 좀 틀린게 있다면 서버 케릭셋 설정이겠네요.
처음에 그부분을 충분히 감안해서 뽑아서 iconv로 컨버팅도 해보고, 뽑을때 케릭셋도 심도있게 고민 해보고, 심지어 서버에서 MYD MYI FRM 파일을 직접 가져와서 넣어봤는데요. 역시 마찬가지 입니다.
왜 이런 증상이 생기는 걸까요? 참고로 vBulletin 이라는 phpbb비슷한 보드 입니다.
그쪽에서 제공하는 백업툴을 쓰면 한글이 가차없이 깨져버립니다. UTF를 지원하는 보드가 아니거든요. (인기가 있음에도 불구하구요)
의심가는 부분 있으시면 가차없이 댓글을 달아주세요 ㅠ
데이터를 보낼 DB환경 : http://bittalk.org/sht.php
데이터를 받을 DB환경 : http://bittalk.canxan.com/sht.php
감사합니다. 좋은하루되세요
==============================================
참고 자료 몇 가지 추가 합니다.
리플 감사합니다.
그리고 한가지 사실을 더 알아냈는데요!
덤프받은 파일에 "뷁" 등의 문자들을 미리 넣어서 import해봐도 데이터가 잘려 들어갑니다.
그런데 테이블들은 collation만 틀리지 전부 다 똑같리 UTF-8을 사용하고 있는것 같습니다.
간혹 첨부파일이나 각종 이미지를 바이너리로 직접 DB에 저장해버리는 이상한 테이블도 있지만, 다 선별해서 그것들하고 별개로 덤프 받았구요.
추가된 사실로 봐서는 my.cnf의 설정상의 문제가 아닐까 싶은데, 옮겨오는 쪽의 서버가 c**e24라서 my.cnf를 순순히 공개해 줄지는 의문입니다; 일단 의뢰인과 이야기 해보도록 하고..
아래는 지적하신 덤프파일의 일부와 받는 서버의 my.cnf의 일부 입니다.
DB를 받는 서버의 my.cnf
[client] port=3306 socket = /var/lib/mysql/mysql.sock ;lower_case_table_names = 2 default-character-set=utf8 [mysqld] port=3306 socket = /var/lib/mysql/mysql.sock init_connect=SET collation_connection = utf8_unicode_ci init_connect=SET NAMES utf8 default-character-set=utf8 character-set-server=utf8 collation-server=utf8_unicode_ci server-id = 1 basedir = blah datadir = blah tmpdir = blah language = blah ;lower_case_table_names = 2 [mysqlhotcopy] interactive-timeout
아래는 덤프 받은 파일의 일부 입니다. 무리없이 잘 나와주네요.
-- Dumping data for table `announcement` -- LOCK TABLES `announcement` WRITE; /*!40000 ALTER TABLE `announcement` DISABLE KEYS */; INSERT INTO `announcement` VALUES (2,'초대장 주고받기 포럼에서는 User+ 이상 글을 읽거나 올릴 수 있습니다 .',1,1198162800,1200841200,'User+ 부터 이용할 수 있습니다\n\nUser에서 User+로 승급할 수 있는 조건은 다음>과 같습니다.\n\n가입후 7일 경과 <span>혹은</span> 글 5개 올리셔야 하고.\n\n둘중 하나만 충족하면 됩니다,\n\n가급 적 댓글보다 thread를 올려주시기 바랍니다.',6,38,29),(3,'저작권 보호 요청은 운영자에게 메일 주시기 바랍니>다.',1,1200236400,1266073200,'저작권에 관한 문제가 있다면 관련 컨텐츠를 삭제하도록 하겠습니다.\r\n\r\n보>호 요청은 으로 메일 주시기 바랍니다.\r\n\r\n감사합니다.\r\n\r\n-bitTalk Team-',56,139,29); /*!40000 ALTER TABLE `announcement` ENABLE KEYS */; UNLOCK TABLES;
감사합니다.
mysqldump를 사용할 때
mysqldump를 사용할 때 4.1 버전부터는 default-character-set을 지정하지 않으면 utf8로 설정됩니다.
따라서 mysqldump를 기본값으로 실행하기도 했고, utf8로 실행하기도 하셨다는데 같은 결과가 됩니다.
euckr로 저장한 데이터가 모두 깨어져서 백업되는 거죠.
반드시 테이블의 문자셋과 동일한 default-character-set으로 지정해줘야 데이터 손실이 없습니다.
테이블의 문자셋이 euckr이라면 mysqldump도 euckkr로 지정해줘야 합니다.
만약 원본 데이터베이스 내에 여러 가지 문자셋이 존재한다면 테이블 단위로 default-character-set 을 다르게 줘서 백업해야 주세요.
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
음..
조사해 봤지만 DB내의 케릭셋은 동일한것 같습니다~
문자셋 문제는...
일부 데이터를 덤프해서 파일을 올려 주시고
my.cnf의 내용도 보여 주시는 것이
조언을 더 쉽게 받으실 수 있을 것 같네요.
서버의 charset, 클라이언트의 charset,
DB의 charset, 테이블의 charset,
덤프 파일 자체의 charset 등이
얽혀 있기 때문에 전체적으로 봐야 할 필요가
있습니다.
앗.
요청하신 부분 올려드립니다~.
감사합니다.
흐흠. 이런 일 있을
흐흠. 이런 일 있을 때 마다 드는 생각이...
그냥 다 무시하고 바이너리로 전부 처리하되 정열시에만 문자셋을 따지도록 하면 어떨까.. 근데 그런 일은 일전에 어디선가 있엇던 거 같군요. 버젼이 얼마였던지는 기억이 안 나지만...
근데, 이미 집어 넣은거 어쩌겠어요 음.. 그냥 프로그램을 고치는 것이 하나의 방법이 아닌가 싶습니다.
----
Lee Yeosong(이여송)
E-Mail: yeosong@gmail.com
HomePage: http://lys.lecl.net/
Wiki(Read-Only): http://lys.lecl.net/wiki/
Blog: http://lys.lecl.net/blog
MSN: ysnglee2000@hotmail.com
----
절이 싫으면 중이 떠나는 것이 아니라, 절이 싫으면 중이 절을 부숴야 한다.
사람천사
저도 처음에
저도 처음에 프로그램의 문제로 접근했었는데요.
phpmyadmin으로 입력하거나, 덤프받은 파일을 미리 "됬,뷁"등으로 조작해서 넣어봐도
똑같이 저 글자와 함께 뒷 내용들은 아에 그냥 잘려버리는 증세가 일어납니다.
본문에서 언급했지만, mysql의 설정 문제가 아닐까 생각해봅니다.
댓글 감사합니다.
1.
1.
init_connect=SET collation_connection = utf8_unicode_ci
init_connect=SET NAMES utf8
부분은 빼십시오.
skip-character-set-client-handshake
한 줄이면 충분합니다.
skip-character-set-client-handshake 는 클라이언트가 보내는 문자셋을 무시하고 서버쪽 문자셋을 사용한다는 의미입니다.
동일한 효과가 있지 않냐고 하실지 모르겠지만, 서버쪽 문자셋을 바꿀 경우
현재는 init_connect 부분과 character-set-server 부분을 둘다 고쳐줘야 하기 때문에 별로 권장하지 않습니다.
init_connect를 사용하는 방법은 skip-character-set-client-handshake 옵션이 생기기 전에 사용하던 방법입니다.
2.
[mysqld] 항목에 있는
default-character-set=utf8
character-set-server=utf8
이 두 줄은 같은 뜻입니다. 따라서 한줄만 적어주시면 됩니다. mysql 매뉴얼에 따르면 향후에는 character-set-server 만 쓸 예정이라고 하므로 default-character-set=utf8 이 라인을 지워주시면 되겠습니다.
3.
collation-server=utf8_unicode_ci
는 적어주신 이유가 있는 건지요?
일반적으론
collation-server는 utf8_general_ci 를 씁니다.
utf8_unicode_ci를 쓰는 특별한 이유가 없다면 utf8_general_ci로 바꾸시던지...
그 줄 자체를 삭제하십시오. (collation-server를 지정하지 않으면 디폴트 값이 utf8_general_ci입니다.)
collation이 엉뚱하게 잡히면 예상하지 못했던 문제가 발생할 수 있습니다.
4.
[client]
default-character-set=utf8
이 항목이 지정되어 있으면 mysqldump 등을 할 때 아무리 default-character-set을 변경해도 적용되지 않습니다.
제 경험상으로는 [client] 항목에 적지 말고,
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
테이블이 MyISAM
테이블이 MyISAM 포맷이라면....
인덱스를 myisamchk 명령으로 재생성해주십시오.
문자셋을 변경해도 기존의 인덱스 파일은 영향을 받지 않기 때문에...
데이터 정렬은 물론 삽입 등에서 이상하게 작동하는 경우가 있습니다.
myisamchk -r -q *.MYI
명령으로 인덱스틀 재성성하고 다시 테스트해보시지요.
단, 그 전에 문자셋이라든지 collation-server 값 등을 바꾸실 일이 있다면 먼저 바꾸시고요.
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
어흑..
자세한 답변 너무 감사합니다.
상세히 적어주신대로 모두 해봤지만 역시나 똑같은 증세입니다.
휴으. 울어버리고싶네요 ㅠ..
무엇이 더 문제일까요..?
저도 비슷한 경험을
저도 비슷한 경험을 가지고 있습니다.
http://kldp.org/node/65089
Mediawiki를 사용중에 생긴 문제긴 하지만
UTF-8을 이용해 한글을 사용하고 있는데
Mediawiki가 mysql을 사용할때는 latin1을 사용했다는 점에서
비슷한 상황같네요.
제가 얻은 결론은
mysqldump --default-character-set=latin1 --add-drop-table --complete-insert -u USERID -p'PASSWORD' DBNAME > DBNAME.sql
로 백업하자는겁니다.
이경우 sql파일은 제대로 안보일수도 있지만
백업,복구는 잘 됩니다.
참고하시고 확인해보세요.
음..
인코딩을 바꿔서 억지로 생성해버리면
import시 글자가 깨져버리네요..
아무튼 댓글 감사합니다.
댓글 달기