나머지...

고객지원 중 얼음이 되다.

by janus posted Dec 08, 2009




벌써 12월의 끝자락….

지난달 초 생각만해도 아찔한 지원이슈가 생각이 난다.

이른 오전 핸드폰에서 나를 부르는 진동이 느껴졌다.

그간 별탈 없이 유지되었던 고객사의 발신이라 편한 마음으로 전화를 받았다.

그런데 이런…. 고객사의 DB에서 사진데이터가 나오지 않는 다는 것이다.

부랴부랴 원격으로 고객사의 서버에 접근하여 확인을 하는 순간 얼음이 되어 버렸다.

누군가 하면서 터치를 해줄 사람이 있었으면….

DB의 특성상 데이터 보존이 중요하고 또한 저장된 데이터들이 고객의 자산과 같다.

설마 고객사에서 데이터를 삭제했을 일은 없을 것이고 어떻게 처리해야 할지 난감한 상황에 봉착했다.

별다른 수가 없어 백업을 이용하여 복구를 수행하려 하였으나, 이미 사진데이터가 없는 상태에서 운영이 되어 앞으로도 뒤로도 갈수 없는 사면초가인지 진퇴양난인지에 빠지게 되었다.

CUBRID에서는 GLO(Generalized Large Object)  시스템 클래스를 이용하여 사진과 같은 멀티미디어 데이터를 저장하도록 되어 있다. 문제의 DB에서는 데이터영역에는 사진데이터가 있지만 ROW에서 참조하는 링크정보가 깨진 것으로 보인다.

고민에 고민을 하던 중 잡머리가 비상하게 굴러가기 시작했다.

Good Idea!!

테스트서버에 정상적인 시점을 기준으로 운영DB를 복원하고 사진데이터를 파일로 dump받은 후 현재 운영DB에 저장시키는 방법이다.

GLO시스템테이블에서  관리용으로 다양한 Method를 제공하는데 그 중 파일로 dump하는 copy_to(), 파일을 DB GLO에 적재하는 new_lo_import(), copy_from() 메소드를 이용하기로 했다.

예를들어 테이블과 데이터가 아래와 같을 경우,
Table Student

             Attribute

                           ID          int,

                           Name     varchar(20),

                           Photo  glo
-------------------------------------------

SELECT * FROM Student;

-------------------------------------------
ID          Name                  Photo

1            AAA                    NULL

2           BBB                     NULL

3           CCC                    NULL

-------------------------------------------

GLO를 상속받은 photo컬럼이 복구대상이다.

ID 1Row에 대하여 객체를 생성한 후 copy_to(‘/tmp/1.jpg’)를 이용하여 /tmp에 저장한다. 저장한 파일을 운영서버에 new_lo_import(‘tmp/1.jpg’)를 이용하여 lo객체를 생성한 후 ID 1photo컬럼에 UPDATE를 수행하여 사진데이터를 복구하는 방법이다.

위에서는 쉽게 이야기를 했지만 사실상 복구대상 테이블은 4개에 총 복구대상이 약 4,000개 이었으므로 Shell Program을 만들어 일괄작업으로 쭉쭉 밀어 넣어 장애를 처리 할 수 있었다.

이와 같이 GLO의 링크정보가 손상된 경우는 극히 드문 경우라 왠지 RPG게임에서 Level up을 한 듯 뿌듯함을 느꼈다.