고기맛을 알아버린 스님

며칠전... (지난 목요일이구나)

엄청난 사고를 쳤다가 수습한 내용을 간략히 적어본다.

예전에 메인 db 서버의 데이터를 delete 문으로 삭제를 한 적이 있다.

삭제를 한 이유는 테이블에 있는 데이터의 용량이 거의 2G를 육박하고 있었기 때문이었다.

참고로 메인 db서버엔 고객db, 회사에서 주력으로 서비스하고 있는 db의 내용이 있어 한마디로 엄청난 압박을 가지고 만져야 하는 서버다.

그래서 여태껏 커널 업그레이드도 못하고, mysql 업그레이드도 못하고 있다.(부담스러워서...)

지난번 delete 문으로 짠 스크립트 cron으로 돌릴때도 거의 뜬눈으로 밤을 새다시피 했었다.

다행히 cron은 제대로 돌았고 데이터의 내용은 날씬해졌지만 데이터 용량의 크기는 마찬가지였다.

검색을 해보니 isam 체크를 해주어야 한다고 했다.

isam 체크를 한다고 한다고 하다 결국은 2달여가 지나갔고 2005년 2월 17일 목요일 새벽 4시 40분에 cron으로 예약해놓고 그날은 푹 쉴 수(?) 있었다.

다음날 아침 출근하니 회사 웹서버가 개판 오분전 이었다.

메인 db 서버의 mysql 데몬이 죽어 있었다.... OTL ... OTL ...

하늘이 노래지는거 같았다.

일단 수습을 하기위해서 mysql데몬을 띄우고 db의 특정 table에 insert 를 못하게 막았다.(서비스는 되어야 하기때문에 데몬을 죽일수는 없다)

침착하게 isam 체크를 해나갔다.

헉..... 그런데 isam 체크도중 에러를 내뿜는 것이었다. 침착하고 계속 추이를 지켜봤다.

isam 체크를 끝내고 mysql 데몬을 죽였다 살렸다.

그리고 체크한 테이블을 테스트 했다..... 헉...

모든 index가 죽어 있었다.... OTL .. OTL ..

진짜 하늘이 노래졌다.

............

문제의 테이블 데이터파일들을 다른 서버(mysql 설치는 되어 있지만 서비스 되지않는)로 옮겼다.
거기서 mysql 데몬을 죽이고 isam 체크를 진~ 하게 했다.

서비스가 되지 않아서 그런지 체크는 20분을 넘기지 않았다.

체크한 파일의 용량을 살펴보니 확실히 날씬해져 있었다.

그 파일들을 다시 메인 db서버에 옮기고 데몬을 재실행 시키니 그제서야 정상적인 결과가 나올 수 있었다.