원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어

출처1 :  http://www.kdug.co.kr/?pgname=home/board&mode=VV&brcode=pds_tech&wrno=2225

출처2 : http://www.ibm.com/developerworks/data/library/techarticle/dm-1010db2instancerecovery/index.html

데이터 손실이나 손상을 복구하는 작업은 백업 데이터베이스에서 데이터를 복원하는 과정을 통해 수행됩니다. 그러나 인스턴스 구성이 손상되었거나 데이터베이스 파티셔닝을 사용하는 경우에는 어떻게 해야 할까요? 서버를 전체적으로 복원하지 않으면서도 효율적이고 효과적으로 DB2 인스턴스 환경을 복원하려면 어떻게 해야 할까요? 이 기사에서는 파티션된 데이터베이스 환경에 필요한 복구 전략과 DB2 인스턴스 백업을 구현하는 방법을 설명하는 과정을 통해 이러한 질문에 답변을 하려고 합니다. 특히, System x와 Power Systems 서버를 기반으로 구성된 IBM Smart Analytics System 환경을 집중적으로 살펴봅니다. 데이터 손실이나 손상을 복구하는 작업은 백업 데이터베이스에서 데이터를 복원하는 과정을 통해 수행됩니다. 그러나 인스턴스 구성이 손상되었거나 데이터베이스 파티셔닝을 사용하는 경우에는 어떻게 해야 할까요? 서버를 전체적으로 복원하지 않으면서도 효율적이고 효과적으로 DB2 인스턴스 환경을 복원하려면 어떻게 해야 할까요? 이 기사에서는 파티션된 데이터베이스 환경에 필요한 복구 전략과 DB2 인스턴스 백업을 구현하는 방법을 설명하는 과정을 통해 이러한 질문에 답변을 하려고 합니다. 특히, System x와 Power Systems 서버를 기반으로 구성된 IBM Smart Analytics System 환경을 집중적으로 살펴봅니다.

소개

이 기사에서는 DB2 인스턴스가 손상된 상황에서 인스턴스를 지원하는 모든 구성 특성을 복원하여 참조할 수 있도록 해당 파일과 환경 설정을 백업하는 방법을 설명한다. 이 기사는 우수 사례 기사 시리즈의 일부로 IBM Smart Analytics System 환경에서의 백업과 복구를 다룬다. 우수 사례 기사 시리즈에 대한 링크는 참고자료 섹션을 참조하기 바란다.

이 기사의 기초가 되는 샘플 환경은 하나의 관리 노드와 두 개의 데이터 노드가 있는 IBM Smart Analytics System 5600이다. 다운로드 섹션에는 이 기사에서 권장하는 대로 파일, 환경 및 구성 설정을 백업하는 데 필요한 명령어가 포함된 예제 스크립트에 대한 링크가 있다. 필요에 따라 예제를 편집하여 예제가 해당 환경에 호환 가능하도록 하자. 그리고 언제나 비프로덕션 환경에서 명령어를 테스트하도록 하자.

실수로 파일 사용 권한을 변경했거나 파일을 삭제한 경우 또는 파일 시스템이 사용 가능하지 않게 된 경우에는 DB2 인스턴스를 사용하지 못할 수 있다. 이러한 시나리오에 신속하고 효과적으로 대응할 준비를 하려면 적절한 인스턴스 복구 계획을 수립해야 한다. DB2 인스턴스와 관련된 파일과 환경 설정을 식별하고 발생할 가능성이 있는 모든 유형의 인스턴스 장애를 복구하는 데 필요한 파일을 제공할 백업 전략을 복구 계획을 통해 정의해야 한다.

인스턴스와 데이터베이스 간의 관계는 절대적인 것이 아니다. 손상된 인스턴스를 삭제한다고 해서 관련된 데이터베이스가 삭제되는 것은 아니다. 데이터는 손실되지 않는다. 인스턴스 구성과 환경을 올바르게 복구할 수 있기만 하면 데이터베이스와 관련된 인스턴스와 카탈로그를 삭제하고 다시 작성할 수 있다.

파티션된 데이터베이스 환경에서 DB2 인스턴스를 백업하고 복구하는 전략을 구현하여 서버를 전체적으로 복구하지 않아도 인스턴스 구성을 복구할 수 있게 하면 다운타임 가능성을 줄일 수 있다.

그림 1에는 파티션된 데이터베이스 환경의 DB2 아키텍처가 표시되어 있다. DB2 소프트웨어는 각 노드에서 실행하고 이 노드에서 데이터베이스 파티션을 지원한다. IBMTEMPGROUP으로 레이블이 지정된 파티션 그룹은 관리 노드와 두 개의 데이터 노드에 걸쳐있다. SDPG와 IBMCATGROUP 파티션 그룹은 관리 노드에 있다. PDGP 파티션 그룹의 범위는 테이블 공간이 위치한 데이터 노드까지이다.

그림 1. DB2 인스턴스 복구 아키텍처

인스턴스 구성

IBM Smart Analytics System은 데이터베이스 파티셔닝을 구현하여 대규모의 병렬 처리 및 선형 확장성을 제공한다. 이러한 환경에서는 인스턴스 대신 데이터베이스를 파티션한다. 관리 노드에서 인스턴스를 작성하면 DB2 소프트웨어를 실행 중인 관련 노드(서버)에서 db2home 디렉토리를 공유할 수 있게 된다. 파티션된 데이터베이스가 제대로 기능하도록 하려면 데이터 노드마다 동일한 방식으로 사용자, 그룹 및 운영 체제 환경을 구성해야 한다. 파티션된 데이터베이스는 데이터베이스 구조를 관리하고 이 구조에 대한 액세스 권한을 조정하는 관리 노드를 통해 관리된다.

IBM Smart Analytics System에는 데이터 노드당 다수의 데이터베이스 파티션이 있다. 각 데이터베이스 파티션에는 프로세서와 메모리, I/O 자원이 할당되며 이 파티션에서 별도의 데이터베이스 컨테이너와 로그, 인덱스 및 자체 데이터베이스 구성 관리자가 유지보수된다. 쿼리는 쿼리를 만족시키는 데 필요한 데이터를 검색하는 코디네이터 함수에 제출된다.

이 기사에서 다루게 될 테스트 클러스터는 세 개의 노드로 구성되며 beluga-bvn-05는 관리 노드이고 beluga-bvn-06과 beluga-bvn-07은 데이터 노드이다. 관리 노드에는 하나의 데이터베이스 파티션이 있으며 각 데이터 노드에는 네 개의 데이터베이스 파티션이 있다. 따라서 테스트 클러스터는 총 9개의 데이터베이스 파티션으로 구성된다.

클러스터에 있는 모든 노드에서 인스턴스가 작성되면 db2nodes.cfg 파일에서 정의한 모든 데이터베이스 파티션에서 데이터베이스가 작성된다. 목록 1에는 db2home/sqllib 디렉토리에 있는 샘플 db2nodes.cfg 파일이 표시되어 있다. 이 파일에는 테스트 클러스터의 구성이 기술되어 있다.

목록 1. 샘플

IBM Smart Analytics System 환경에서는 DB2 인스턴스 홈 디렉토리가 관리 노드에 있는 /shared_db2home 디렉토리가 된다. 이 파일 시스템은 GPFS나 NFS를 통해 다른 노드에서 공유하게 된다. 기타 노드는 로컬 파일 시스템에 /db2home으로 마운트된다. 각 노드의 /db2home 파일 시스템은 관리 노드에 대한 마운트 지점이므로 디렉토리 백업은 관리 노드에서만 수행하면 된다.

인스턴스 백업 전략

DB2 환경을 위한 백업 전략에서는 운영 체제와 DB2 인스턴스 및 DB2 데이터베이스를 다루어야 한다. 모든 복구 시나리오는 이렇게 특정 백업을 통해 처리된다. 대상을 정하여 복구하면 다운타임이 최소화된다는 점에서 이러한 방식이 효과적이라고 할 수 있다.

인스턴스 백업 프로세스를 전체 백업 스케줄에 통합한다. 환경 구성을 변경하기 전과 후에 인스턴스 구성을 백업한다. 인스턴스를 백업하기 위해 다음과 관련된 모든 세부사항을 기록한다.

l           소프트웨어 버전

l           라이센스

l           사용자 및 그룹

l           구성 설정이 포함된 파일

l           인스턴스 디렉토리

이 섹션에서 나열한 파일과 설정 및 변수를 모두 백업해야 한다. 이러한 파일은 크기가 작지만 복구 후에 모든 것이 제대로 되었는지 조정하고 유효성을 검증하기 위해 사용할 수 있는 가치 있는 정보를 포함하고 있다. 이외에도 추가로 도움이 필요한 경우에는 IBM 지원 센터를 통해 세부적인 백업 관련 정보를 요청할 수 있다.

이 섹션에 있는 네 개의 테이블은 각각 백업해야 하는 파일과 구성 설정으로 이루어진 네 개의 카테고리 중 하나를 나타낸다. 표 1과 2에는 각 노드에서 백업해야 하는 데이터가 표시되어 있다. 표 3과 4에는 관리 노드에서 백업해야 하는 데이터가 표시되어 있다. 이러한 두 가지 백업을 DB2 인스턴스 소유자로서 실행할 수 있다. 백업은 다운로드 섹션에 있는 두 개의 스크립트로 표현된다.

표 1. 운영 체제 파일 백업

표 2. 운영 체제 정보 캡처

표 3. DB2 홈 디렉토리로 구성된 tar 파일 작성

표 4. DB2 관리자와 관련 구성의 출력 및 저장

인스턴스 장애

시나리오 인스턴스 장애는 대부분 인간의 실수나 서비스 장애, 파일 손상 때문에 발생한다. 장애는 환경 변수의 변경으로 인한 장애에서 DB2 소프트웨어에서 참조하는 운영 체제 환경 파일의 항목이 수정되면서 생긴 장애에 이르기까지 다양하다. 문제의 원인을 아는 경우나 그렇지 않은 경우에 따라 복구 시나리오의 카테고리를 나눌 수 있다. 문제의 원인을 아는 경우에는 파일이나 구성 설정을 수정하면 문제를 해결할 수 있다. 원인을 모르는 경우에는 인스턴스를 완전히 복구해야 한다. 프로덕션 환경에서는 원인을 발견하는 속도보다 복구를 수행하는 속도가 더 중요하다.

해당 환경에서 어떤 복구 시나리오를 수행할 수 있는지 확인한 다음, 장애 시나리오와 관계없이 인스턴스를 복구하는 데 사용할 수 있는 백업 전략을 적절히 시행한다. 적절한 복구 계획을 수립해야 하는 네 가지 일반적인 장애 시나리오는 아래에서 설명한다.

l    관리 노드에 있는 db2home 디렉토리가 제거되었거나 인스턴스가 갑자기 삭제되었다. 관리 노드에 있는 db2home 디렉토리는 파티션된 데이터베이스에 있는 다른 모든 노드에서 공유한다. 홈 디렉토리의 내용이 손상되거나 제거되면, 인스턴스를 사용할 수 없게 된다. 

l    인스턴스 구성이 손상되었다. 구성이나 DB2 바이너리 파일이 손상되거나 삭제되면 인스턴스를 사용할 수 없게 된다. 이러한 파일로는 .rhosts, db2nodes.cfg 및 글로벌 레지스트리가 있다. 또한, 환경 변수가 갑자기 수정되면 이러한 시나리오가 발생할 수 있다. 

l     데이터와 관련된 공유 db2home 파일 시스템, 대기, 사용자 또는 InfoSphere 웨어하우스 애플리케이션 노드가 삭제되었다. 이러한 디렉토리가 제거된 노드에서는 인스턴스를 사용할 수 없게 된다. 

l     인스턴스 디렉토리의 사용 권한이 갑자기 변경되었다. db2home 디렉토리에서 파일이나 디렉토리 사용 권한이 변경되면 DB2를 사용할 수 없게 된다.

인스턴스 복구 절차

이 섹션에서는 운영 체제의 구성을 확인하는 절차와 인스턴스를 삭제하고 다시 작성하는 절차를 살펴본다. 참조한 백업 파일은 다운로드 섹션에 있는 샘플 백업 스크립트를 사용하여 작성한 것이다. 설정을 확인할 때는 장애 노드에 설정된 값과 이 노드에서 백업한 파일을 비교한다. 운영 체제 파일과 설정을 편집하려면 root 계정으로 액세스해야 한다.

1. DB2와 관련된 모든 태스크에서 DB2 인스턴스 소유자를 사용한다:

a.       다음과 같이 영향을 받은 노드에서 운영 체제의 구성을 확인한다. 인스턴스 사용자와 분리 사용자가 /etc/passwd에 존재하는지 확인한다.

b.       관련된 DB2 그룹 계정이 /etc/group에 존재하는지 확인한다.

c.        각 백업 사본에서 /etc/services와 /etc/hosts를 비교하여 필요에 따라 수정하거나 복원한다.

d.       해당 시스템과 관련된 소프트웨어 패키지를 열거하여 백업 파일에 표시된 것과 비교한다. 모든 변경 원인을 분리하고 판별한다.

e.       사용자 한계(ulimit), 마운트 지점(/etc/fstab), 운영 체제 레벨(oslevel) 및 crontab 항목을 비교하고 확인한다. 모든 변경 원인을 판별한다.

2. 다음과 같이 영향을 받은 노드에서 손상된 인스턴스를 삭제한다:

a.       db2ilist 명령을 사용하여 해당 인스턴스가 여전히 인스턴스 목록에 존재하는지 판별한다. 해당 인스턴스가 손상되지 않은 경우에는 마운트와 네트워크 문제를 확인한다. db2iupdt 명령을 사용하여 사용 권한 문제를 수정한다.

b.       db2idrop <instance> 명령을 사용하여 부분적으로 손상된 인스턴스를 삭제한다.

c.        db2iset 명령을 사용하여 관련된 프로파일 정보와 구성 매개변수를 제거한다. (예: db2iset -d bcuinst2)

3. 다음과 같이 영향을 받은 노드에서 인스턴스를 작성하고 구성한다.

a.       db2icrt 명령을 사용하여 root 사용자로 관리 노드에서 인스턴스를 작성한다. DB2 소프트웨어를 설치한 제품 디렉토리에서 이 명령을 실행한다. 이 기사의 테스트 클러스터에서는 제품 디렉토리가 /opt/IBM/dwe/db2/V9.7/instance이다. 다음과 같이 명령을 실행한다.

db2icrt -u bcufenc2 bcuinst2

여기서 bcufenc2와 bcuinst2는 인스턴스 소유자의 사용자 ID이다.

b.       데이터베이스 관리자 구성 매개변수를 dbm.cfg.out 백업 파일에 있는 매개변수와 비교하고 필요하면 복원한다.

c.        $DB2HOME/sqllib/db2nodes.cfg 파일을 백업 버전과 비교하고 필요하면 바꾼다.

d.       레지스트리 변수를 db2set.out 백업 파일에 있는 변수와 비교하고 필요하면 다시 적용한다. 예를 들면, 다음과 같이 DB2COMM 변수를 tcpip로 설정해야 할 수도 있다.

     db2set DB2COMM=tcpip

e.       $DB2HOME/sqllib/userprofile 파일을 백업된 파일과 비교하고 필요하면 바꾼다.

4. 다음과 같이 라이센스 파일을 추가하고, 영향을 받은 노드에 있는 데이터베이스의 목록을 작성하고 DB2를 시작한다.

a.       백업 파일 세트에서 db2ese.lic 파일을 복원하고 다음 명령을 실행한다.

db2licm -a db2ese.lic

라이센스 파일을 찾을 수 없으면 db2start 명령은 SQL8000N 오류를 리턴한다.

b.       백업 세트의 db2.list.database.directory 및 db2.list.node.directory 파일에 표시된 것에 따라 노드와 디렉토리 목록을 작성한다. 예를 들어, 테스트 클러스터에서 이러한 작업을 수행하려면 다음과 같은 명령을 실행한다.

catalog tcpip node beluga-bvn-05 remote beluga-bvn-05 server 50000

catalog database BCUDB as BCUDB at node beluga-bvn-05

c.        DB2를 시작한다. DB2 HA(High Availability) 기능을 사용할 경우에는 해당 환경에 적합한 시스템 종료 및 시작 절차를 참조한다.

알려진 장애의 복구

이 섹션에서 기술한 바와 같이 인스턴스 장애의 원인을 아는 경우에는 완전한 복구 작업을 수행할 필요가 없다. 특정 복구 단계에서 사용 권한 문제뿐만 아니라 네트워크와 마운트 문제를 수정할 수 있다.

n    비관리 노드에 있는 인스턴스 소유자 홈 디렉토리가 제거되었다.

관리 노드가 아닌 노드에 있는 인스턴스 홈 디렉토리는 마운트된 파일 시스템이다. 다음 단계를 수행하여 이러한 장애를 복구한다.

1.         다음과 같이 마운트 명령을 사용하여 영향을 받은 노드에 있는 파일 시스템을 마운트한다.

      mount /db2home 

2.         인스턴스 소유자로서 데이터베이스 관리자를 시작한다. (예:db2start) 

참고: 고가용성 환경에서는 다른 명령을 사용해야 할 수도 있다. 이런 경우에는 해당 사용자 안내서를 참조한다.

n    인스턴스 디렉토리에 대한 사용 권한이 갑자기 변경되었다.

db2home 디렉토리 특히, sqllib 디렉토리에서 chmod나 cp 명령을 실행하면 DB2 소프트웨어가 파일을 읽거나 쓰거나 실행할 때 장애가 일어날 수 있기 때문에 인스턴스가 사용 불가능하게 될 수 있다. 예를 들면, 이 기사의 테스트 클러스터에서는 관리 노드에서 chmod 명령을 실행했다. 이렇게 하면 파일 사용 권한 오류로 인해 db2start 명령이 실패하게 된다. 목록 2에는 장애가 발생하는 상황이 표시되어 있다.

목록 2. 사용 권한을 변경한 데 따른 장애

bcuinst2@beluga-bvn-05:~>cd ~/sqllib
bcuinst2@beluga-bvn-05:~>chmod -R 444 *
bcuinst2@beluga-bvn-05:~> db2start
-bash: /db2home/bcuinst2/sqllib/adm/db2start: Permission denied
SQL6031N  Error in the db2nodes.cfg file at line number "<line>".
Reason code "<reason-code>".
Explanation:
The statement cannot be processed because of a problem with the
db2nodes.cfg file, as indicated by the following reason codes:
1 Cannot access the sqllib directory of the instance.

이러한 시나리오에서는 다음과 같은 단계를 수행하여 소유권과 사용 권한 값을 다시 적용한다.

1.         ~/sqllib에 있는 각 파일은 인스턴스 사용자 ID와 db2 인스턴스 그룹이 소유해야 한다. 이렇게 하려면 관리 노드에서 다음과 같은 명령을 실행한다.

chown db2inst2:db2igrp /db2home/bcuinst2/sqllib/*

여기에서 bcuinst2와 db2igrp은 각각 인스턴스와 그룹 계정이다. 

2.         db2iupt 명령을 실행하여 db2home 디렉토리를 업데이트하고 설치된 DB2 소프트웨어에 기반을 둔 공통 파일을 바꾼다. db2iupdt 명령을 사용하여 인스턴스를 업데이트하려면 먼저, 인스턴스를 처리하기 위해 실행 중인 모든 프로세스를 중지해야 한다. db2iupt 명령을 실행하면 ~/sqllib 디렉토리 아래에 있는 파일이 변경된다. 목록 3에는 테스트 클러스터에서 이러한 단계를 수행하는 방법이 표시되어 있다.

목록 3. 설치된 DB2 소프트웨어를 기반으로 하는 인스턴스를 db2iupdt 명령을 사용하여 업데이트하기

결론

인스턴스가 손상되어 결국에는 사용할 수 없게 되는 상황을 신속하고 효과적으로 복구할 수 있도록 DB2 인스턴스 백업 전략과 복구 전략을 구현해야 한다. 인스턴스 백업 전략과 복구 전략을 함께 사용하면 인스턴스가 손상되는 상황에 직면했을 때 운영 체제를 완전히 복원해야 하는 상황을 피할 수 있다. 이렇게 하면 그러한 상황에서 경험하게 되는 다운타임을 대폭 줄일 수 있다.

참고자료

l     developerWorks에 있는 다른 DB2 우수 사례 기사를 읽어보자.

l     DB2 Database for Linux, UNIX, and Windows Information Center에는 관련된 IBM InfoSphere Information Server 제품 및 기능뿐만 아니라 DB2 제품군과 기능을 사용하는 방법이 기술된 정보가 있다.

l     developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.

l     무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.

l     Twitter의 developerWorks 페이지를 살펴보자.

l     developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.

다운로드