막무가내 DBA의 DISK 장애 대처

그런데 replication 을 구성해놓은 master 서버가.. 돌아가셨다.
정확히 말하면 master DB가 아니라 master DB의 데이터를 가지고있는 disk가.. 사라지셨다.
음? 출장가셨나? ㅡ,.ㅡ

컴퓨터에 C: D: 드라이브가 있고, 내 데이터는 D: 에 들어가있는데
어느날 갑자기 D: 윈도우 탐색기에서 사라졌을떄의 기분.. 느껴보셨쎄요?
안겪어봤으면 말을하지마세요 -_-

각설하고.
어떻게 빨리 서비스를 정상 작동시킬 수 있을까?
이렇게 문제가 발생했을 때 서비스를 정상적으로 돌리는것은 결국 master -> slave로 절체하는 시간 싸움이다.

CIBRID는 기본적으로 Broker - DBserver 구조로 되어있다.
다시 말해서
client(JDBC) -> Broker -> DBServer로 request가 전달된다.
client는 connection url이라는 string에 brokerIP, databasename을 이용하여 broker로 연결한다.
broker라는 놈은 databases.txt라는 파일에 난 어느host의 어느 database로 연결할 수있다고 설정할 수있다.

이제 요 broker-server라는.. 하등 쓸모없게 보였던놈이 진가를 발휘할 때가 온 것 같다.
(사실 broker는 생각보다 많은 일을 하지만.. 일반 사용자 혹은 개발자들은 broker가 왜 필요하냐고 묻는 사람이 태반이다)masterDB의 디스크가 출장가셨다. 연락 두절이다. 근데 slaveDB는 한국에 계신다.

음. 다른 DB같으면 master - slave로 절체하려면 어떻게 할까?

박모팀장님께 여쭈어봤다.
master 죽으면, 개발자가 application에서 configuration file의 connection url 수정해서 배포해야한단다.

CUBRID는?
이 broker라는 놈이 있는 서버의 databases.txt에서의 DB가 존재하는 host명을 slave server로 수정해주고 broker를 restart하면 끝이다.
그럼 아래 그림처럼 되겠지?

물론, 어떤 상황에서건 restart는 해야한다.
그러나 application의 connection url을 바꾸건 뭘 바꾸건
web server 대수만큼 수정해야한다. (각 config 파일은 각 web server에 존재하므로)
뭐. 일괄 수정해서 배포해주는 시스템이 있어서 상관없지않냐? 라고 할지도 모르겠다. 쿨럭.

그런데 생각해보면, 어차피 장애가 나면 DBA는 서버에 들어와서 장애 처리를 해야한다.
그때 파일 하나 수정 띡 해주면 바로 정상 서비스이다.
개발자 입장에서 볼땐 손하나 까딱 안하고 master에서 slave로 절체되어주신다.

그리고 master의 복구가 완료되어 돌아와야할 땐?
그때도 손하나 까딱 안해주셔도 벌써 다 처리가 되어있다지...?
아니면 뭐.. slave 를 그냥 master로 두고 master가 있던 서버에 slave를 구축해도 되고.
그건 DBA 마음대로 정하면 될 일이다.

장애 감지 후 처리하는데 소요된 시간은,
databases.txt 파일 수정 후 broker restart하는데 통틀어 한 10초 걸렸다.

앞으로 요 broker 라는 놈, 좀더 예뻐해줘야겠다.
어쩌면 CUBRID는 나중에 백조가 될 운명을 가진 미운오리새끼가 아닐까?
시간이 지나면, 다른 DBMS와 다르다고 놀림받고 괄시받았던 것들이
CUBRID만의 특징과 장점이 되어 세계에 이름을 떨칠지도 모르는 일이다.

요녀석. 빨리빨리 자라거라 ^^

이미지 출처 : 네이버 포토앨범
http://imagebingo.naver.com/album/image_view.htm?uid=dadayoko&bno=26185&nid=4178