안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.
이번주는 V8.2 새로운 기능의 3번째 시간으로, HADR 이라는 기능에 대해 알아보도록 하겠습니다.
이러한 새로운 기능은 검토를 통해 계속적으로 XpertMon 에 적용될 것입니다.
많은 도움이 되시길 바라며, 혹시라도 알고 싶은 내용이나 주제가 있으시다면 메일로 보내주십시오.
참조하여 반영하도록 하겠습니다.

---

High Availability Disaster Recovery

HADR 이란?

HADR 은 고가용 재해복구로서, Fixpak 7번에 추가된 내용입니다.
간단히 말해서, 현재 운영되고 있는 데이터베이스를 다른 시스템에 복제하고
동기화시켜 두는 것입니다. 이것은 AIX의 HACMP 나 Solaris의 Sun Cluster와 같은
고전적인 고가용을 의미하는 것이 아닙니다. HACMP와 HADR은 다른 기능입니다.
아마도 많은 분들이 HACMP는 로컬 복구에, 그리고 HADR은 원격복구에 사용하실 겁니다.
물론 HADR을 로컬 복구에 사용할 수도 있습니다.
제대로 사용하시려면 HADR은 데이터베이스 복구에 사용하고 HACMP는 시스템 복구에 사용하는 것이 옳겠죠.

HADR 동기화 옵션

HADR에서는 sync / nearsync / async 의 세가지 동기화 옵션이 있습니다.

1. sync 모드 : primary 시스템에서 로그의 내용이 디스크에 쓰여지면, 마찬가지로
   standby 시스템에서 동일하게 수행되어야 작업이 종료되는 모드
   
2. near sync 모드 : standby 시스템이 로그를 건네 받았을 때 (디스크에는 적용되지 않은 상태)
   성공 메시지를 primary 시스템에 보내는 것을 제외하고는 sync 모드와 동일.
   
3. async 모드 : primary 시스템은 로그가 standby 시스템에 전달되는지에 대한
   확인사항을 기다리지 않고, TCPIP 스택에 log 내용을 계속적으로 보냄.

여기서 어떤 모드를 사용할 것인지는 primary 시스템이 깨져서 standby 시스템으로 전환할 때
얼마만큼의 데이터 유실을 감수할 수 있는지에 달려 있습니다.
만약 데이터 유실을 허용하지 않겠다면 sync 모드를 선택해야 할 것입니다.
하지만 이 경우 standby 시스템이 다운되어 있거나, 네트워크에 장애가 있다면 문제가 됩니다.
이전에도 언급했지만 sync 모드에서는 primary 시스템이 standby 시스템으로부터 로그를
제대로 받고 디스크에 기록했다는 확인을 기다리기 때문입니다.
async 모드를 선택했을 때, primary 시스템이 깨지고 바로 직후에 standby 시스템이 깨진다면
적재되던 로그의 정보를 잃어버리게 됩니다.

HADR 전제 조건

주 / 보조 시스템은 서로 운영체제가 동일해야 합니다.
서로 다른 운영체제에서는 HADR이 지원되지 않습니다.
Window 와 AIX, AIX와 Sun은 물론 Window200과 Window2003 의 환경도 지원하지 않습니다.
메모리 등도 거의 같아야 합니다.

HADR 설정 단계
설정은 제어센타를 통해서도 수행할 수 있지만, 여기서는 명령문으로 수행하겠습니다.
단계는 다음과 같습니다.

• 주 데이터베이스의 로그모드를 archive로 설정
• 주 데이터베이스에서 데이터베이스 구성변수를 변경
• 주 데이터베이스 백업
• 백업파일을 보조 시스템으로 전송
• 보조 시스템에 데이터베이스 복구 (roll forward 모드로)
• 주 데이터베이스의 HADR 구성변수 변경
• 보조 데이터베이스의 HADR 구성변수 변경
• 보조시스템의 서비스 파일 갱신
• 주 시스템의 서비스 파일 갱신
• 각 시스템의 보조(alternative) 서버 정의
• 보조 시스템에서 HADR 시작
• 주 시스템에서 HADR 시작

이상의 12단계로 HADR을 설정할 수 있습니다.

HADR 설정 환경

1. 주 시스템
   • 시스템 명 : SY1
   • DB 명 : DB1
   • Instance명 : DB2
   • 포트번호 : 50000
2. 보조 시스템
   • 시스템 명 : SY2
   • Instance명 : DB2
   • 포트번호 : 50000

HADR 설정 1단계
주 데이터베이스의 로그모드를 archive로 설정하고 다른 데이터베이스 구성변수도
필요에 맞게 변경합니다. circular 로그나 무한로그를 사용할 때는 HADR을 구성할 수 없습니다.

>db2 update db cfg for DB1 using logretain on >db2 update db cfg for DB1 using logindexbuild on >db2 update db cfg for DB1 using indexrec restart

SY1에서 주 데이터베이스를 백업받습니다.

>db2 backup db DB1 to fs1

SY2에 데이터베이스를 복구합니다. SY1에서 SY2로 백업파일을 복사하거나,
SY2에서 SY1의 에 접속할 수 있어야 합니다. 후자의 경우 명령은 다음과 같습니다.

>db2 restore db DB1 from fs1 replace history file

SY1의 UDF와 stored procedure를 SY2로 복사합니다.
이 작업 이후에 주 데이터베이스의 UDF나 stored procedure가 변경되거나 새로 생성되면
보조 데이터베이스에서 같은 작업을 수동으로 해 주어야 합니다.

SY2에 복구된 데이터베이스를 SY1에 카탈로그 합니다.

>db2 catalog tcpip node hm remote ipaddr-of-SY2 server 50000 remote_instance DB2 >db2 catalog db DB1 as DB1R at node hm

HADR 설정 2단계
주/보조 데이터베이스의 HADR 데이터베이스 구성변수를 변경합니다.

• HADR_LOCAL_HOST - 로컬 호스트명 혹은 IP Address
• HADR_LOCAL_SVC - 로컬 HADR 프로세스의 TCP 서비스 이름/포트번호
• HADR_REMOTE_HOST - 리모트 호스트명 혹은 IP Address
• HADR_REMOTE_SVC - 리모트 HADR 프로세스의 TCP 서비스 이름/포트번호
• HADR_REMOTE_INST - 리모트 서버의 인스턴스 이름
• HADR_SYNCMODE - 동기화 모드
• HADR_TIMEOUT - 실패한 통신시도 전에 HADR 프로세스가 대기하는 시간(초)

HADR 설정 3단계
주/보조 데이터베이스의 서비스파일을 갱신합니다.
양쪽 시스템 모두 HADR_LOCAL_SVC, HADR_REMOTE_SVC 에 설정된 값으로 갱신합니다.
이때 서비스 번호는 기존 인스턴스 서비스 포트번호와 다른 서비스 번호를 부여하여야 합니다.
각 시스템의 보조(alternative) 서버를 정의합니다.

>db2 update alternate server for database DB1 using hostname ip-addr port 50000

SY1 에서는 ip-addr 에 SY2의 IP 주소를 적어주고, SY2에서는 SY1의 IP 주소를 적어줍니다.

HADR 시작
보조 시스템에서 HADR을 시작합니다.

>db2 start hadr on database DB1 as standby

주 시스템에서 HADR을 시작합니다.

>db2 start hadr on database DB1 as primary

HADR 정보 확인
HADR의 동작은 get snapshot 명령으로 확인할 수 있습니다.
snapshot 결과의 마지막 부분에 HADR 정보가 나옵니다.

HADR Status Role = Primary State = Peer Synchronization mode = Nearsync Connection status = Connected , xxxxxxxx Heartbeats missed = 0 Local Host = yyyyyyyyy Local Service = DB2_HADR1 Remote Host = zzzzzzzzz Remote Service = DB2_DADR2 Remote Instance = DB2 timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000000.LOG, 0, 00000000007D0000 Standby log position(file, page, LSN) = S0000000.LOG, 0, 00000000007D0000 Log gap running average(bytes) = 0

이제 주 시스템에서 실행하는 update 문 등에 대해서 로그가 보조 시스템으로 적재됩니다.

FailOver 명령
어떤 경우에 주 시스템과 보조 시스템 간의 전환(failover)이 필요할 때도 있을 것입니다.
이런 경우 TAKEOVER HADR 명령으로 전환을 수행할 수 있습니다.
시스템 전환이 필요한 경우 보조 시스템(SY2)에서 다음과 같이 입력하면 됩니다.

>db2 takeover hadr on db DB1

두 시스템에 대해 get snapshot 명령을 실행하면 SY2가 주 시스템이고 SY1이 보조시스템으로
바뀐 것을 확인 할 수 있습니다.

만약 SY1으로 접속했던 클라이언트가 있었더라도 오류복구(failover) 이후 조치할 사항은 없습니다.
이유는 ACR을 사용하고 있고, 각각의 시스템에 서로 상대 쪽 서버를 보조 서버로
지정해 주었으며, 접속에 사용하는 user ID와 password를 동일하게 주었기 때문입니다.

만약 SY1의 DB1에 접속한 클라이언트가 select 문을 TAKEOVER HADR 명령이 수행된
시점에 던졌다면, 클라이언트에서는 SY2의 데이터베이스에 접속하기 위해 connect 명령을
실행할 필요 없이 select 문만 다시 던지면 됩니다.
응용프로그램에서는 SQL30108N 메시지(접속 실패 후 재접속 했음을 의미)를 감지하고,
해당 메시지를 받으면 select 문을 다시 던질 수 있게 프로그램 되어있어야 합니다.**

각 시스템의 데이터베이스 상태는 SY1이 보조 모드이고, SY2가 주 모드 입니다.
- 위에서 TAKE OVER HADR 명령을 수행했기 때문입니다.
다시 오류복구를 원한다면 현재 주 시스템인 SY2에서 TAKEOVER HADR 명령을 수행하면 됩니다.
그러면 원래의 설정(주 시스템 - SY1, 보조 시스템 - SY2)으로 돌아가게 됩니다.

만약 SY1의 전원이 내려가있다면 어떻게 될까요? 이때는 자동전환이 이루어지지 않습니다.
보조 시스템에서 수동으로 TAKEOVER HADR 명령을 실행해야 하며,
BY FORCE 옵션을 함께 주어야 합니다.
BY FORCE 옵션을 주지 않으면 보조 시스템에서는 주 시스템에서 데이터베이스를
전환할 수 있다는 메시지를 보낼 때까지 기다리게 됩니다.
하지만 SY1은 전원이 내려가 있어서 보내 줄 수 없죠. 그래서 BY FORCE 옵션이 필요합니다.
만약 TAKEOVER HADR 명령을 BY FORCE 옵션 없이 실행했다면,
옵션을 추가해서 다시 한 번 명령을 실행하시면 됩니다.

주 시스템의 상태를 체크하고 만약 주 시스템이 동작하지 않을 때 자동으로
TAKEOVER HADR 명령을 실행하도록 할 스크립트를 작성해야 하는가에 대한 의문이
생길 수도 있습니다. 하지만 그렇게 할 필요는 없습니다.
주 시스템과 보조시스템 사이의 네트워크에 순간적 이상이 생기면 보조 시스템은
주 시스템에 이상이 발생해서 더 이상 동작하지 않는다고 판단합니다.
하지만 클라이언트와 주 시스템간의 네트워크(주-보조 네트워크와 다른 네트워크)는 정상입니다.
이때 스크립트가 TAKEOVER HADR 명령을 실행하면 SY2는 자신이 주 데이터베이스라고
판단합니다. 하지만 SY1도 주 데이터베이스로서 작동하고 있습니다.
결국 2개의 주 데이터베이스가 생기고 서로 상대에게 업데이트를 하는 좋지 않은 상황이 됩니다.
이런 이유로 TAKEOVER HADR 명령은 수동으로 입력하는 것을 권장합니다.
시스템 전환을 해야 할 것인가에 대한 결정을 내리는데 드는 시간이 2개의 주 데이터베이스가
생긴 상황을 해결하는 시간보다는 훨씬 짧습니다.

BY FORCE 옵션을 주었다면, SY1은 오류복구 이후 준비(standby)상태가 아닙니다.
따라서 SY1이 주 시스템이 되도록 재전환 하기 전에 데이터베이스를 재동기화 해주어야 합니다.

HADR 환경을 설정할 때, 보조시스템의 데이터베이스는 롤포워드 펜딩 상태입니다.
시스템 전환이전에는 데이터를 확인 할 수가 없습니다.
그래서 get snapshot 명령의 LOG GAP 값이 적절한지 살펴보는 것이 중요합니다.

만약 주 데이터베이스에서 COPY NO 옵션으로 로드 작업을 수행하면 보조 데이터베이스에서는
복구불능 상태로 표시됩니다. 따라서 COPY YES 옵션을 지정해야 합니다.
다른 사용자들이 COPY NO 옵션으로 로드작업을 수행하지 못하도록
DB2_LOAD_COPY_NO_OVERRIDE 라는 새로운 레지스트리 변수를 사용하십시오.
이 레지스트리 변수는 COPY NO 옵션을 허용하지 않고 대신 COPY YES로 인식하게 합니다.
COPY YES 옵션으로 주 시스템에서 로드작업을 수행하게 된다면, 보조 시스템에 복사본을
쓸 디렉토리가 사용가능한지 확인할 필요가 있습니다.
이것이 중요한 이유는 보조 데이터베이스가 로드 명령으로 사용된 로그를 진행할 때
로드 명령문에 지정된 디렉토리를 찾아봅니다.
만약 해당 디렉토리에서 로그를 발견하지 못하면 보조 시스템의 테이블 스페이스를
복구불능상태로 만듭니다. 그리고 이런 문제는 오류복구가 일어났을 때에야 발견할 수 있습니다.
그러므로 주 데이터베이스에서의 로드작업은 신중하게 수행해야 합니다.

주 서버에서 UDF나 stored procedure가 생성되면 그것들도 복사를 해주어야 합니다.
만약 복사를 못하게 되면 시스템 전환시 해당 UDF나 stored procedure를 사용할 수 없습니다.

위와 같이 UDF와 stored procedure를 양쪽 시스템 모두에 대해 관리하고,
주 데이터베이스에서 로드 작업을 주의 깊게 실행하는 등 신중한 구축과 운영을 통해
고가용성의 세계에 새롭게 나타난 HADR을 가치 있는 도구로 사용하시기 바랍니다.

---

XpertMon for DB2 UDB V2
DB 사업부
Tel : 02-2108-1458
Fax : 02-2108-1459
Mobile : 011-896-6545
E-mail : hjlee@iteg.co.kr
URL : http://iteg.co.kr