서비스 중인 DB가 터졌다. (Tibero 5)

사실 터진건 저번주 금요일이다.
터졌다고 표현하는게 맞을까? Out of memory 이슈로 tibero5.b 서비스를 재시작 하게 되었다.
기기 자체가 나보다 나이가 많기에 DB가 올라가있는 서버를 재부팅하기에는 무서워서 DB 프로세스, 티베로만 재부팅 진행했다.
tbdown 실행하고 tbboot를 실행했다.
소름이 돋고 손에 땀이나고 다리가 떨리고 식은땀이 흘렀다.
tbdown은 되었지만 tbboot가 에러를 내뿜으며 실행되지 않았다.
c1.ctl , c2.ctl을 찾지 못해 실행이 되지 않았다.

나는 여기서 왜 사람들이 대기업 대기업 하는지를 깨달았다.
DB에 문제가 생기고 서비스에 지장이 가자마자 순식간에 많은일이 진행되었다.
하청에 근무함에도 불구하고 귀중한 경험이었다.
개발자 네트워크의 중요성을 깨달았다.
5분도 안되어 서비스 api를 막고 공지를 띄우고 연락에 연락을 돌려 유능한 dba와 연결하여 두시간 채 안되는 시간에 하드웨어 나이가 30세가 넘은, 유지보수가 진행되지 않은 기기의 프로세스를 살려내는것을 보고 소름이 돋고
아… 우물안의 개구리구나 싶었다.
배울게 정말 한참 많이 남았구나 싶었다.
자극이 많이 되었다.
혼자 개발하고 모델링하는것과는 차원이 달랐다.
버전관리부터 일단 재부팅 하고 보는것과 차원이 달랐다.

Tibero 5 버전을 살리신 대기업 dba분의 프로세스는 가볍게 아래와 같았다.
1. Ha solution이 살아있는가 확인
2. Ha solution프로세스가 살았다면 복구를 ha solution에 부분 전담
3.  해당 프로세스가 죽었다면 tbdown clean, tbboot clean 시도.
4. 이번 케이스의 경우 DB프로세스가 죽으며 마운트가 싹다 풀려 DATA1/c1.ctl, DATA2/c2.ctl 파일, tbdown, tbboot 파일을 찾지 못했다.
5. /etc/fstab 에서 스토리지 마운트 확인
6. Ha solution으로 인한 직접 마운트 부분 주석 해제 후
mount -a로 마운트
7. VIP, 버츄얼 ip가 풀려 서비스의 소스코드를 물리적인 IP로 뱐경하여 직접 연결.

이였다.

충격적이었다.
MySql도 겨우 조금 아는 정도인데 그분은 나와 나이차이가 크게 나지 않음에도 불구하고 진짜 티맥스도 유기한 tibero 5버전에 대해 대기업 팀장급의 질문들에 대해 딜레이가 없이 대응하고 여러가지 케이스를 시도해 보며 솔루션을 도출해 냈다.

처음으로 사람이 직업적으로 멋있다는 생각이 들었다.
나도 더욱 정진해야겠다 싶었다.
자바를 하지만, 파이썬도 함께 하지만
한쪽이라도 제대로 알고있다면 그분처럼 멋있는 사람이 될수도 있지 않을까? 하는 희망이 생겼다.