2006-03-14일까지. 둔대 웹 서버 게시판 복구 로그

천신만고 끝에 일단 새 하드디스크로 복사는 완료했다. 정상적으로 뜨는 시작 페이지.
하지만 게시판으로 들어가기만 하면 홈페이지가 먹통이 된다.
이유는 mysql 데몬이 게시판 접속만 하면 죽어버리는 것. 
그냥 죽는 게 아니라 비정상적인 종료(크래시)가 되기 때문에 브라우저에서 먹통이 된다는 사실.

문제는 데이터베이스. tundae 데이터베이스가 문제다. 교수학습 도움센터로 쓰는 study DB는 오류가 없어 정상접속이 가능했다.

데이터베이스가 문제라... 복구를 해야 한다. 
데이터는 차지하고서라도 데이터베이스에 접근했을 때 mysql 데몬이 비정상적으로 죽는 것만은 막아야 할 게 아닌가.

검색끝에 알아낸 정보 isamchk (DB복구 유틸)
http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/Crash_recovery.html

isamchk는 그다지 유용하지 못했다. 예전 데이터베이스 형식인 ISAM 형식을 복구할 수 있는 데다 그마저도 복구를 시도하니 Crash.
그 와중에 알아낸 매뉴얼 사이트 

A.4.1 What To Do If MySQL Keeps Crashing
http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/Crashing.html

이번엔 MyIsamchk 를 시도한다. 새로운 버전의 데이터베이스인 MYISAM을 체크하는 유틸.
이번엔 별 무리없이 스캔된다. 

다음에 계속 : 2006/03/10

---

이제 명령어를 사용하여 데이터베이스 체크를 시도한다.

myisamchk -s  tundae/*.MYI 

에러가 난 테이블이 좌르르르르륵 나온다. 한 번에 볼 수도 없다. 이렇게 되면 화면에 뜬 에러내용을 파일로 저장하는 
명령을 써 봄직도 한데, 내가 안쓴 것은, 안되기 때문이었다!!

myisamchk -s  tundae/*.MYI > error.txt : 안된다..(-_-;;;)

도리가 없다. 화면 맨 아래쪽에서 눈에 보이는 대로 복구를 들어가는 수 밖에.

myisamchk -r  tundae/avatar_member_table.MYI

이러니 복구가 된다.

그리고 나서 다시 -s 옵션으로 잘못된 것 재스캔. 방금 복구한 넘은 안나온다.

하다 보니 커맨드 창에 스크롤바가 보인다. 옳다구나, 대략 에러가 난 테이블이 
한 번에 10개는 보이는 것 같다.
스크롤 바를 올리고서 테이블 이름 확인하고 복구 명령내리고, 다시 올려서 테이블 이름 확인하고
복구 명령 내리고...

이래도 문제가 있는 것이 한 번 복구 명령 내리면 그 결과 화면 때문에 스크롤 바가 줄어들어 
에러 테이블 확인이 쉽지는 않았다.

대략 한 번 -s 옵션 주고 체크하고(myisamchk -s  tundae/*.MYI) 스크롤바질 하여 복구하는 것이 3-4개 테이블.
하지만 이 과정을 몇 번이나 했어야 할까요... 

복구 끝나고 나서 복구한 테이블을 세어 보니 300여개다. 줄잡아 5-60번은 그짓을 했나 보다.

이제 MyIsam 테이블 복구는 끝났다. 하지만 울학교 마이시퀄은 2001년에 설치를 시작한 것이라서 
Isam 형식의 테이블이 있는 게 문제다. 
쉽게 isamchk 명령으로 하면 되지 않느냐겠지만 isamchk -s  tundae/*.ISM 하면 바로 크래쉬.

인터넷엔 아무리 찾아도 Isamchk 크래시 현상에 대해선 안 나온다! 

이틀동안 고민....

생각을 바꾸자 하여 오늘 Isam 테이블을 MyIsam 으로 바꾸는 방법을 찾았다. 의외로 쉽게 나오는 해답

MySQL 들어가서 커맨드 프롬프트에서 ALTER TABLE tbl_name TYPE = MyISAM; 명령으로 바꾸네?

바로 실행 들어갔다. 
다행히 전처럼 디비에 접근만 하면 Mysql 이 죽지는 않아서 무사히 이 명령을 수행할 수 있었다.
명령 수행 후 데이터베이스 데이터 디렉토리를 보니 ISM, ISD 확장자 파일들이 MYD, MYI로 바뀌는
것이 보인다. 
게다가 MyIsamchk -s 옵션으로 확인해 보니 문제가 없다고 나왔다. 잘 되려나...

그렇지만 이 ISM 파일은 몇개냐 하고 세어 보니 무려 80개. ALTER 명령을 80번 주어야 할 참이다. 
이런 노가다가 있을까.

다음에 계속 : 2006/03/13

---

위 방법으로 모든 Isam 테이블을 MyIsam 형식으로 바꾸어 놓고 홈페이지 DB에 접속하니, 접속이 잘 된다.
잘 된다.... 문제가 있긴 하다. zetyx_admin_table 이 0 바이트가 되어서 모든 게시판이 안나온다는 것만 빼곤.

Isam테이블을 MyIsam으로 바꾸는 과정에 문제가 있었던 듯. 윈도에서 하는 작업은 결국 실패.

한참을 고민했다

마지막으로 찾아낸 생각은, 원래 리눅스 서버 하드디스크 안에 있는 MySQL데이터를 살려 보는 것. 
레드햇 8.0의 레스큐 모드로 부팅한 상태에서도 다행히, MySQl 데몬은 성공적으로 떠 주었고, 그 안에서 isamchkm Myisamchk 명령을 이용해 DB를 복구했다.
윈도에서 isamchk -s  를 했을 땐 바로 크래시 되던 것이 리눅스에선 잘 된다. 아무래도 MySQL과 윈도의 궁합이 100% 맞지 않는 것 같다.

다 복구한 DB를 mysqldump 명령으로 추출 뒤 조심스럽게 윈도 하드로 옮긴다. 타르볼 압축으로 한번, 복사로 한번.

윈도 부팅 후 복사한 타르볼 파일을 풀려고 하니, 압축파일에 문제가 있댄다. 제길... 
게다가 phpmyadmin 에서는 아무 문제가 없는 SQL 쿼리파일인데도 쿼리가 없댄다. 

복구불능.

다시 리눅스 레스큐 모드로 부팅 후 이번엔 아예 Mysql 데이타 디렉토리 자체를 타르볼로 압축하여 윈도 하드로 보냈다.

또 윈도로 부팅 후 복사했던 데이터 디렉토리를 찾아보니, 그게 없다... 분명히 아까 리눅 상에서 확인했었는데도, 지금 윈도상에서 확인하니 없다.
왠 도깨비 짓인지.

이번엔 다른 프로그램으로 복구를 시도하기로 했다.

http://www.webyog.com/sqlyog/download.html

위의 링크에 있는 SQLLOG 라는 프로그램을 설치하고 다시 DB에 접속해 본다. 

접속이 된다.

이번엔 다시 위의 프로그램에서 아까 아무 문제가 없었던 SQL 쿼리파일을 불러 보았다. 뭔가 되는 느낌.
한참을 읽어들이더니 다 된 것 같다.

마지막으로 홈페이지에서 제로보드 어드민으로 들어가 보니........

된다. 

빙고.

10여일 동안 한 노력의 결실이다.

참조 http://database.sarang.net/?criteria=mysql&keyword=myisam+%BA%AF%C8%AF

한 문제가 더 남았다. 제로보드 데이터 부분이 완전히 복구가 안되었네...