텍스트큐브(textcube) 1.7.2 버전으로 업그레이드 했다.
얼마후 서버를 이전하기 전에 업그레이드를 해보기로 했다.

백업만 받아놓고, 무작정 덮어쓰기를 해버렸다.

큰 문제는 없는 듯.


# 몇몇 문제점.
1. 음. 몇몇글이 안뜨고 있다. 아마도 플러그인과 충돌이 나는 듯.
  좀더 보니, 글에 댓글이 있는 경우 안뜨네. 댓글 관련 플러그인을 살펴봐야 겠다.

잠깐 살펴보니, 다음 플러그인이 충돌이 일어나는지 작동시키면 뜨지 않는다.
 - 댓글/방명록 이모티콘표시
 - 새창으로 열기 링크
 - JP Entry Hits Plugin
일단 위 플러그인들을 해제하니 글이 잘 뜬다.

2. 그리고, 업로드시 이미지 미리보기가 안 보인다.(왜 그렇지? vista ,xp 모두 그러네.)
  요건 모르겠다. 미리보기창이 그냥 하얗게만 보인다.

3. .htaccess 가 바뀐다고 했는데, 그것때문인지.
  http://taemy.experlab.com/wiki  라고  textcube 디렉토리 밑으로 wiki 를 운영하고 있는데, 접근이 안된다.
  따로 rewrite rule 을 설정해 줘야 할 듯 하다.

추가 : 다음 LTS 버전인 Hardy Heron 에서는 dapper(LTS) 에서 바로 업그레이드 하는 방법을 제공한다.
https://help.ubuntu.com/community/HardyUpgrades
번거롭게 dapper -> edgy -> feisty -> gutsy -> hardy 로 업그레이드 할 필요는 없겠다.


지난글에 dapper 에서 gutsy 나 hardy 로 업그레이드 하려고 했다.
vmware 에서 테스트를 해보니, 업그레이드 후에 문제가 생겼다.

몇가지 패키지들이 이상하고, locale 의 사용방법이 틀린듯 하다.
결정적으로 업그레이드 후에 콘솔에 에러메시지가 끊임없이 계속나온다(커널에러)

바로 dapper 에서 gutsy 로 가지 않고, dapper -> edgy -> feisty -> gutsy 의
방법으로 업그레이드를 해야 할 듯 하다.

https://help.ubuntu.com/community/UpgradeNotes
의 권장방법으로 업그레이드 할 예정이다.

최신방법(update-manager-core)은 직접적으로 안되나 보다.(edgy 부터 지원하는 듯)

apt-get install update-manager-core
do-release-upgrade
순서대로 하는 방법으로 하는 것이 최선일 듯 하다.(그렇지만, 너무 긴 여정이다)


# 기존에 업그레이드 하던 방식.

/etc/apt/sources.list 의 저장소를 바꾸고
apt-get update
apt-get dist-upgrade

위 방법은 ubuntu 측에서 권장하지 않는 사항이다.
dapper 까지는 별 탈 없이 잘 사용했다.(hoary -> breezy -> dapper )

1) dapper -> feisty 를 먼저 시도해보고, 이것도 안되면 edgy 부터 차례로.
그러고보니, edgy 지원기간이 08년4월까지기 때문 에 dapper->feisty 업그레이드가 안된다면
4월에 모두 업그레이드 해야 한다는 말이네.

hardy 정식버전이 나오면 LTS 버전간의 업그레이드를 지원해주려나?
나같이 LTS 버전을 주 사용으로 하는 사람이 꽤 있을 듯 한데.(아닌가? ^^)

2) 일단 dapper -> feisty 로 업그레이드 하는데,
gutsy 때의 패키지 문제는 비슷해 보였지만, 오류메시지는 보이지 않는다.
edgy 를 뛰어 넘고 업그레이드 해도 될지는 좀더 테스트 해봐야 겠다.

[apache2 package 에서 문제]
업그레이드 중에 apache2-common 과 apache2.2-common 이 충돌이 생겨 중지가 되는데
일단 apache2-common , apache2-mpm-prefork , libapache2-mod-php5 , php5 등을
삭제했다가 나중에 다시 설치하면 된다. 
그런데, init script 에 변화가 있는듯 하니, /etc/init.d/apache2 , /etc/apache2 를 이름을 바꾸거나,
삭제한후 설치하는 것이 좋을 듯 하다.(업그레이드시에 보통 이전 설정파일을 그대로 쓴다)

3) 드디어 feisty -> gutsy 로 업그레이드.

apt-get install update-manager-core
do-release-upgrade

이 방법으로 해보려는데, 잘 안된다. (No new release found)
do-release-upgrade -d 로 하니 되긴 하는데, 맞는것인지는 모르겠다.(정확한 동작방식이 어떻게 되지?)

업그레이드가 정상적으로 진행되고, 재부팅. 그런데, 콘솔의 tty 가 열리지 않는다. 왜지?
부팅메시지에 이런게 있다.

init:/etc/event.d/tty1:16: Unknown stanza
init:/etc/event.d/tty2:16: Unknown stanza
init:/etc/event.d/tty3:16: Unknown stanza
init:/etc/event.d/tty4:16: Unknown stanza
init:/etc/event.d/tty5:16: Unknown stanza
init:/etc/event.d/tty6:16: Unknown stanza

해당위치의 파일(/etc/event.d/tty1) 을 열어보면, 끝부분이 이상한 것을 알 수 있다.

respawn
/sbin/getty/38400 tty1exec /sbin/getty 38400 tty1

처럼 나와 있다.

respawn
exec /sbin/getty 38400 tty1

이렇게 고친다. tty1 ~ tty6 까지 고쳐줘야 한다.
아! 로그인을 못하는데, 어떻게 고치냐고? ( ssh 등으로 원격접속은 가능하다. ssh 는 꼭 열어놓기를.)

dapper -> gutsy 업그레이드시 콘솔에 엄청나게 뿌려대는 에러는 없었다.

4) 긴여정이었지만,  dapper -> feisty -> gutsy  로 edgy 를 뛰어넘고 업그레이드 가능하다
다른 것들도 이렇게 업그레이드 해야 겠다.


Hardy LTS 버전은  dapper LTS 버전에서 바로 업그레이드 하는 방법을 제공하면 좋겠다(정말, 꼭)

예전 4.0.x 에서 4.1.x 로 업그레이드 는 조금 복잡하고 주의가 필요했다.(1,2,3)
4.1.x 에서 5.0.x 로의 업그레이드는 그에 비해 간단한 편이다.

우분투에서는

apt-get install mysql-server-5.0

으로 업그레이드 후에 (이때 기존 4.1 버전은 apt-get 이 자동으로 제거)

mysql_fix_privilege_tables

만 해주면 OK

너무 간단한가?

성능향상이 있다고 하는데, 아직은 모르겠다.
4.0.x 에서 5.0.x 로 바로 업그레이드는 어떤지 테스트 해봐야 겠다.
보통 4.0.x -> 4.1.x -> 5.0.x 의 순서를 권장하던데, 상황봐서 진행
현재 4.0.x 를 쓰고 있는 마지막 서버도 마저 업그레이드 예정.


# 메뉴얼
- http://www.mysqlkorea.co.kr/sub.html?mcode=develop&scode=01&m_no=20034&cat1=2&cat2=35&cat3=82

# 참조
- http://www.mysqlkorea.co.kr/gnuboard4/bbs/board.php?bo_table=community_03&wr_id=164
- http://database.sarang.net/?inc=read&aid=23327&criteria=mysql&subcrit=columns
- 성능향상 : http://www.mysqlkorea.co.kr/gnuboard4/bbs/board.php?bo_table=community_06&wr_id=391
- 5.0 새버전 : http://jay2.tistory.com/198

이 개발로그(devLog) 는 블로그 / 위키 / 포럼 / 톡박 으로 운영되고 있습니다.
상단의 오른쪽(검색아래) 부분에 해당 연결이 있습니다.


톡박이라고 그냥 자유로운 이야기를 하는 게시판입니다.
metaBBS 라는 심플한 게시판을 사용하고 있구요.

설치해 놓고 그냥 있었는데, 오늘 svn 버전(최신 버전-r389)으로 업그레이드를 하였습니다.
http://metabbs.org/snapshot/ 에서 최신버전을 다운 받으시면 됩니다
svn 버전은 개발버전이기 때문에 불안정 할 수도 있는데, 업그레이드하고 보니 별 문제는 없습니다.



개발버전에서 openID 지원이 있어 테스트겸 업그레이드를 했습니다.
정상적으로 작동을 합니다.
그런데, 왠지 오픈아이디 로그인한 후 다른사이트를 갔다고 오니, 로그인이 풀려버리네요.
그점 빼고는 별 다른 문제는 없네요.
오픈아이디 관련해서는 최종적으로 위키, 포럼쪽도 오픈아이디를 적용할 예정입니다.


metaBBS 가 현재 0.9RC2 까지 정식으로 공개된 상태입니다.
앞으로의 계획이 다음과 같다고 합니다.(http://metabbs.org/forum/viewtopic.php?id=182 )
ditto 님이 거의 혼자 개발중이신 것 같구요.
아무래도 릴리즈 주기가 길지만, 심플하고 안정적이라 추천해드립니다.

개발자분께 화이팅도 같이 ^^ 아자!!

현재 ubuntu 버전은 breezy , dapper 를 거쳐 edgy 가
릴리즈 된 상태이다. (feisty 가 개발중 4월 발표예정)

그런데, 뜬금없이 때늦은 업그레이드에 대한 리포트가 웬말이냐!!
하겠지만, 혹시나 해서 글로 남겨 놓는다.

우분투를 데스크탑이 아닌, 서버용도로도 쓰고 있어서, 한단계씩
늦게 업그레이드 하고 있다.(테스트 기간이 필요하다.)

업그레이드 테스트한 PC 는 데스크탑 + 서버 용도로 사용하고 있다.
amd64 , nvidia geforce 5200 , via mainboard
onboad SATA HDD , SCSI HDD , SATA , IDE 하드가 장착되어 있다.

ubuntu hoary amd64 버전 설치후 breezy 로 업그레이드 한 후 사용하다가
이번에 dapper 로 업그레이드 하였다.

업그레이드 하면서 문제 정리

• 업그레이드 시
  • 몇몇 패키지 설치 문제
  • apt-get -f install 으로 문제해결(메세지가 나온다)
    
  • /var 폴더를 파티션 마운트가 아닌, symbolic 링크로 했을때 업그레이드 문제.
  • 내 경우 /var 를 별도 파티션이 아닌 /system/var 로 심볼릭 링크로 했었다.
  • 이런경우 /var 를 별도파티션으로 마운트하고 업그레이드 한다.
    
  • apt-get 으로 업그레이드시 /.root 에 마운트 후에 업그레이드를 한다.
  • amd64 - ldd 패키지가 다르면서 거부, ldd 삭제후 시도
  • /usr/bin/ldd.amd64 를 ldd 로 복사하기전 메세지
  • ldd 를 삭제후 시도한다.
    
• 업그레이드 후
  • sdc , sdd 순서가 바뀌어 버림 - fstab 수정후 부팅
  • SCSI 컨트롤러와 SATA 컨트롤러 가 서로 바뀌었다.
  • SATA 컨트롤러를 나중에 설치했었는데, 업그레이드 하면서 먼저 인식한듯 하다.
  • fstab 를 수정하면 상관없음.
    
  • var/run , var/lock 비정상적인 마운트 문제 - tmpfs 사용의 문제
  • var 가 별도의 파티션으로 되어 있는 경우 정상적으로 마운트가 되지 않을 수 있다.
  • 우분투 포럼을 참조
  • 루트파티션을 마운트 하고 /var/run , /var/lock 디렉토리를 만들어 준다.
    
  • ifrename 삭제 - udev 체재로 바뀌면서 없어진듯.
    • ifrename 을 설치하려고 하면 udev 외 ubuntu-base .. 등 중요패키지도 같이 삭제하려함.
    • /etc/rcS.d/S40ifrename 을 삭제한다.(별 필요없는 과정)
      
      
• /etc/iftab 문제 - 정확한 mac address 설정
• breezy 에서 iftab 에 대해 참조만 하는듯 하다.
• 그런데, dapper 에서 엄격히(?) 검사를 하는지, iftab 의 mac 주소가 틀리면 ethX 를 잡아주지 못한다.
• ifconfig -a 로 나오는 정확한 mac 주소로 고쳐준다.

위 문제들은 장착된 하드웨어가 단순하거나, 서버용도로만 사용하거나, amd64 가 아닌경우
위와 같은 문제가 발생하지 않고, 별 무리없이 진행될 것이다.

다른 PC(서버전용)로 테스트 했을때 위 /etc/iftab 문제를 제외하고 별 무리없이 업그레이드가 가능하였다.

ps. 조금 늦은 업그레이드라 dapper 사용기간은 짧아질 것 같다.

이전편 1회에 이어서..

처리순서를 간단히 정리하자면.(1회의 언급한 내용)

1. 업그레이드 전 dump (euckr , utf8 확인)
2. mysql 업그레이드 ... ( 3.x , 4.0.x -> 4.1.x or 5.x )
   
3. set names euckr 명시 (euckr 환경인경우)
   
4. table 의 Engine , Charset 를 조정.
5. 덤프 데이터 restore
6. 확인.

# 위 업그레이드 절차를 좀더 자세히 설명한다.

1. 업그레이드 전 dump (euckr , utf8 확인)
   • 명령은 간단한다.(추가적인 옵션등은 검색)
     
     • mysqldump {DB_name} > DB_name.sql
     • mysqldump {DB_name} -u {user_name} -p{password} > DB_name.sql
     • mysqldump -F -n --add-drop-table {DB_name}> DB_name.sql
       
       
2. mysql 업그레이드 ... ( 3.x , 4.0.x -> 4.1.x or 5.x )
   • 각 배포판, APM 배포판 별로 업그레이드 한다.
     • 업그레이드 방법은 별도로 찾아본다.
   • 위 단계에서 dump 파일이 있으니, 안심해도 된다.
   • 다시 롤백을 해야할 상황은 없길 바란다.
     
     
3. set names euckr 명시 (euckr 환경인경우)
   • dump 파일을 euckr , utf8 에 맞게 iconv 같은 것으로 변환을 하는 경우도 있는데, 굳이 필요 없다.
   • 이전 환경이 euckr 이면 dump 파일 맨 위에 "set names euckr" , utf8 이면 "set names utf8" 이라고 한줄 추가해 준다.
     
     
4. table 의 Engine , Charset 를 조정.
   • 4.0.x 를 덤프하면 create table 부분에  " ) Type=MyISAM " 이라고 되어 있을 것이다
   • 덤프파일에서 Engine , Charset 을 적절히 바꾼다.
     • " ) ENGINE=InnoDB DEFAULT CHARSET=euckr " 형태로 바꾸어 준다.
     • 각각 InnoDB/MyISAM , euckr/utf8 로 적절한 환경으로 바꾸어 준다.
       
       
5. 덤프 데이터 restore
   • 위 수정된 덤프파일을 저장한다.
   • mysql {DB_name} < DB_name.sql 으로 복구한다.
     
     
6. 확인(my.cnf 등의 옵션 조정)
   • 데이터가 이상없는지 확인.
   • euckr 환경인 경우
     • my.cnf 의 mysqld 항목에 init_connect = 'set names euckr' 를 추가한다.
   • utf8 환경이라도 init_connect = 'set names utf8' 이라고 넣어주는 것이 좋다.
     • php 에서 위 설정을 해주지 않으면 latin1 으로 기본 설정된다.
   • chartset 에 관한 부분은 추후 더 정리할 예정.

# 업그레이드시 주의사항

1. 테이블 charset 변경시 : alter table {테이블명} convert to character set utf8 명령으로 하면.
   
   • multibyte 를 사용하는 db 의 경우 필드 값이 반으로 줄어 버림
   • 그래서 dump 로 처리하는 것이 좋음
   • 덤프파일의 create table 항목의 charset 을 변경하는 방식으로 처리.
     
2. 4.0.x 에서 dump 시 euckr , utf8 인지 확인
   • euckr 인 경우 덤프파일의 맨위에 set names euckr , utf8 은 set names utf8 를 삽입
   • 이부분만 주의하면 무리없이 진행가능.
     
3. php 에서는 기본이 latin1 으로 잡힘
   • my.cnf 에 default-character-set 을 설정확인.
     
   • init_connect ='set names euckr' 최종 값이 설정됨.
   • init_connect 가 php 의 설정에 영향을 미침.
4. dump 파일의 ENGINE , CHARSET 을 변경가능 (InnoDB , MyISAM) , (euckr , utf8)

ps. 좀더 자세한 설명이지만, 배포판별 mysql 업그레이드 방법, 세부 mysql 옵션등의 설명은 생략하였다.
   더 자세한 설명은 메뉴얼을 참조한다.

많은 웹사이트들이 APM - Apache + PHP + Mysql 조합으로 운영되고 있다.

Apache 는 1.x 버전에서 2.x 로의 버전 업그레이드가 되었고,
PHP 는 4.x , 5.x 버전으로 업그레이드가 되고 있다. 이제 6 버전이 개발중에 있다.

mysql 의 버전은 3.x 버전을 거쳐, 4.0.x , 4.1.x , 5.x  버전으로 업그레이드가 되었다.
그런데, mysql 의 버전 업그레이드를 하면서 내부적인 변화때문에 데이터의 호환성, 변경 문제를 겪게 되었다.
크게 (3.x ,4.0.x)  와  (4.1.x ,5.x) 의 두 그룹 사이의 업그레이드에 주의하면 된다.

한글 환경을 사용하는 국내에서는 charset(euckr , utf8) 에 조금만 주의를 하면
어렵지 않게 업그레이드 할 수 있다.

약간은 철지난 이슈이긴 하지만, 몇가지 주의사항 및
쉽게 업그레이드 할 수 있는 방법을 정리하고자 한다.

먼저 자신의 환경을 파악한다. euckr 환경인지, utf8 환경인지.
업그레이드시 euckr 환경으로 할지, utf8 환경으로 할지 등을 점검하고 업그레이드 한다.

가장 흔한 조합은
1. euckr 환경에서 사용하다가 업그레이드 euckr 환경을 계속 유지.
2. euckr 환경에서 utf8 환경으로 업그레이드
3. 테이블이 latin1 형식에서 euckr , utf8 환경으로 업그레이드
이 정도일 듯 하다.

가장 쉽고, 최선의 방법은 dump 후 restore 하는 방법이다.(당연하다고? ^^ )
아무튼 무작정 업그레이드 시도하기전에 백업은 필수!!

처리순서를 간단히 정리하자면.

1. 업그레이드 전 dump (euckr , utf8 확인)
2. mysql 업그레이드 ... ( 3.x , 4.0.x -> 4.1.x or 5.x )
   
3. set names euckr 명시 (euckr 환경인경우)
   
4. table 의 Engine , Charset 를 조정.
5. 덤프 데이터 restore
6. 확인.

구체적인 방법은 다음회에...(2회 보기)

ps. 총 3-4 회에 걸쳐 정리할 예정.