Background Image
조회 수 742 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부
CUBRID는 10.1 version 이상부터 restoreslave란 명령어를 제공한다.
CUBRID 9.3.x version 까지는 온라인 재구성을 위해 자체적으로 제공되는 shell script를 사용하였으나, 
10.1 version 이상부터는 restoreslave 명령을 통해 보다 편하게 작업을 할 수있다.

해당 명령어를 통해 master의 구동 상태와는 상관 없이, slave를 재구축 할 수 있으며, 시나리오는 아래와 같다.

1. HA 서비스 중, 이중화가 깨졌을때.
 (1) 필요 환경 : master - slave의 이중화 환경.

 ha_status.png
 (2) 필요 파일 : master 서버의 backup file
 (3) 시나리오
  - DB의 이중화가 깨지는 것을 재연하기 위해 slave의 db_ha_apply_info의 데이터를 삭제한다.
  - slave의 heartbeat를 종료한다.
  slave)
      $> csql -S -u dba --sysadm demodb 
      sysadm> delete from db_ha_apply_info;

  select_apply.png

  - 위의 이중화 로그를 삭제하였을 경우, 동기화는 더이상 이루어지지 않는다.

  - 위의 행위로 인하여 DB 이중화가 깨졌다고 판단하고 이중화복구를 진행하여보자.
  - master에서 backup 받은 backup file은 slave에 옮겨놓은 상태이다.
  
  slave)
      $> cubrid service stop   -- cubrid sevice 종료
      $> ps -ef | grep cubrid  -- CUBRID process가 모두 내려갔는지 확인한다.
      $> cubrid restoreslave -s 'master' -m host_name -B . -o result.txt demodb
       * -s 옵션은 backup을 받은 node를 지칭한다. ('master', 'slave', 'replica')
       * -m 옵션은 master node의 hostname을 지칭한다.
       * -B 옵션은 backup file의 경로.
       * -o 옵션은 output message
  - restoreslave가 모두 완료 되었으면 cubrid heartbeat start를 통하여 정상 구동여부를 확인한다.

 restoreslave.png



2. HA 서비스 중, 외부 요인으로 인하여 slave의 DB가 삭제되었을때.
 (1) 필요 환경 : master - slave의 이중화 환경
 (2) 필요 파일 : master 서버의 backup file
 (3) 시나리오
  - slave의 서비스를 중지 시킨 후, slave DB 디렉토리를 삭제한다.
  slave)
      $> cubrid service stop
      $> rm -rf db_name or cubrid deletedb db_name 
  - 이후, slave의 databases.txt파일을 참조하여 해당 위치에 동일한 디렉토리를 생성한다.
       * 만약 deletedb로 삭제하였을 경우, $CUBRID/databases/databases.txt파일을 master의 내용과 동일하게 설정하여야한다.
  
  - 명령어에서 알수 있듯이 DB에 대한 restoredb기능이 있기 때문에, DB 복구후 자동으로 이중화 작업이 진행된다.
  - master에서 backup 받은 backup file은 slave에 옮겨놓은 상태이다.
  
  slave)
      $> cubrid restoreslave -s 'master' -m host_name -B . -o result.txt -u demodb
       * -u 옵션 : databases.txt 파일을 참조하여 해당 위치에 DB를 복구한다.
  - 위의 시나리오와의 차이는 -u 옵션으로 databases.txt에 등록된 위치에 DB를 복구할 수 있다는 것이다.
  - restoreslave가 모두 완료 되었으면 databases.txt 파일의 db_vol_path에 해당 DB가 정상적으로 복구되었는지 확인한다.
  - 마지막으로, cubrid heartbeat start를 통하여 정상 구동여부를 확인한다.
  
3. 고려사항.
  (1) restoreslave 명령을 사용하여 DB 복구 시 최초 복구 시점은 backup 시점이다.
  (2) 즉 backup 시점 이후의 모든 트랜잭션은 구동 후 반영되어진다.
  (3) 이정보는 cubrid applyinfo 명령을 통하여 확인이 가능하며, delayed log page count 가 0 이 되어야, 모든 트랜잭션을 반영한 것이다.
  (4) 그렇기 때문에 해당 작업이 이루어지기 전에 master에서 backupdb를 실행하여 최신의 backup file로 작업하는 것이 용이하다.

  applyinfo.png



  1. DBMS? 힐끗 다른 쪽을 바라봤다

    시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다. 그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다. 그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다...
    Date2018.12.28 Category나머지... By조성룡 Views991 Votes0
    Read More
Board Pagination Prev 1 Next
/ 1

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales