지니워의 일상다반사

어제 밤, 잠이 안와서 이리저리 뒤척이다가 새벽 세시쯤이 되어서야 잠이 들었는데 잠들고 얼마 있지 않아 slave server 중 한대에서 장애가 발생했다. 모니터링 하시는 분들이 대표님께 연락을 했고 대표님께서 일단 서버가 제대로 돌아가게끔 조치는 해두고 주무셨단다. 출근해서 db server의 log부터 살펴보았다. 이런 저런 error message들이 많이 나타나고 있었는데 인과관계를 잘 따져 이 error들이 나오게 된 근본문제를 찾기 시작했다. 발견. 서버를 재부팅하거나 mysql을 재시작 직후 event scheduler 를 실행하지 못했다는 로그를 발견했다. 이걸 단서로 원인을 찾기 시작. 1. DB에 접속한 다음 mysql 변수 중 event scheduler과 관련된 것이 있는지 찾아보..

어제에 이어 오늘도 DB에 관한 포스팅을 쓴다. 원래는 어제 포스팅 말미에 언급했던 것처럼 댓글에 DB튜닝의 결과를 적으려했으나 내용이 꽤 길어질 듯 하여 새롭게 포스팅을 작성한다. 일단 어제 걸어뒀던 delete작업은 약 세시간여만에 포기하기로 결정하고 프로세스를 kill해버렸다. '으잉?왜?????????????????????????????' 라고 생각할 수도 있겠다. delete작업을 중지했던 이유는 간단한데 시간이 엄청나게 오래걸리기 때문이었다. 이는 MySQL의 알고리즘 때문인데 데이터에 대한 작업 수행속도를 높이기 위해 Index를 설정해놓아도 테이블에서 일정 수치 이상의 데이터 조작이 감지되면 Index를 사용하지 않고 데이터를 모두 읽고 가공하려 하기 때문이다. 쉽게 이야기해서 100이라는..

DB용량이 하루가 다르게 커져가고 있다. 하루에 작성되는 글의 수도 엄청날 뿐더러 그것보다 더 많은 코멘트, 꽤나 많은 용량의 이미지와 플래시등과 같은 첨부파일 등등...블로그가 공개된 곳이다보니 DB규모를 정확하게 적을 순 없지만 테이블 하나의 크기가 거의 100G에 육박하는 것도 있으니 그 크기가 얼마나 큰지 대략 짐작이 갈 것이다. 문제는 DB의 크기가 커지다보니 컨트롤 하기가 힘들어질 뿐더러 결정적으로 하드 디스크용량의 문제때문에 어떻게든 튜닝포인트를 찾아 불필요한 Data를 삭제하여 용량을 확보하는 것이 시급한 문제로 부각되기 시작한 것이다. 회사에 DBA가 없기 때문에 이 문제는 개발자 한명이 진행을 하기로 했지만 SE가 강건너 불구경 할 수 있는 처지는 아니다. DB는 서버에 설치되어 있고 ..