안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.
DB2 UDB V8.2에서는 여러 재해복구기능(High Availability Disaster Recovery)을 제공하는데,
그 중에서 이번 주에는 ACR (Automatic Client Reroute) 기능에 대해서 다루어 보겠습니다.
아무쪼록 많은 도움되시길 바라며, 혹시라도 알고 싶은 내용이나 주제가 있다면 메일로
보내주십시오. 참조하여 반영하도록 하겠습니다.
What failure? Leveraging the DB2 UDB V8.2 ACR
(Automatic Client Reroute facility)
데이터베이스 서버가 깨지면, 해당 서버에 접속되어있던 클라이언트에서는 접속이 끊어지고
사용자의 화면에 응용프로그램 오류를 띄우는 통신에러를 받게 됩니다.
(일반적으로 SQL30081N 이 떨어집니다.)
여기서는 ACR 기능이 오류가 발생했을 때 오류발생 메시지를 떨어뜨리는 대신 standby 서버에
재 접속하는 방법에 관해 살펴 보겠습니다.
DB2 UDB V8.2 ACR 기능은 클라이언트 응용프로그램이나 데이터베이스로의 접속에 있어서
기본 데이터베이스로의 접속이 불가능 할 경우 대체 데이터베이스로 접속합니다.
시간이 다소 걸린다든지, 트랜잭션을 다시 수행하게 해야 할지도 모르지만,
SQL30081N 오류(접속중단 오류메시지)는 발생하지 않습니다.
이런 ACR 기능을 사용하기 위해서는 서버와 클라이언트 모두 DB2 UDB V8.2 이상이어야 하지만,
서버와 클라이언트간의 레벨이 일치할 필요는 없습니다.
ACR 기능은 주로 다음과 같은 고가용 구성에 주로 사용됩니다.
- 파티션 / 비파티션 데이터베이스 클러스터
- DataPropagator(DPropR)-style replication
- IBM HACMP(High Availability Cluster MultiProcessor) 같은 고가용 클러스터링 소프트웨어
(High Availability clustering software)
- HADR 환경 - ACR은 HADR과 연결되어 클라이언트 응용프로그램이 접속한
데이터베이스의 오류상황 발생시에도 중단을 최소화 하면서 작업을 계속하게 합니다.
예를들어, HADR-적용 데이터베이스가 깨지면, DBA가 수동으로 끊어진 모든 데이터베이스
접속을 다시 구축해야 하지만 ACR을 사용하면 이러한 과정을 피할 수 있고,
응용프로그램에 투명성을 부여합니다.
- 보조 DB2 Connect 서버의 오류해결 뿐만 아니라, 데이터 공유 그룹을 위한 Sysplex환경에
좋은 영향을 주는 DB2 Connect 환경에 사용됩니다.
자동 ACR 구성
ACR의 목표는 DB2 UDB for Linux, Unix and Windows 응용프로그램에서 communication의
유실로부터 복구를 가능하게 하고, 그리하여 응용프로그램으로 하여금 중단을 최소화하면서
작업을 계속하게 하는 것입니다. 이름에서 알 수 있듯이, 리라우팅이 이 기능의 핵심입니다.
그러나 응용프로그램을 살아있는 데이터베이스 서버로 리라우팅하는 것은 클라이언트
접속이 대체(alternative) 서버의 위치를 알고 있을 때만 가능합니다.
주(primary) 서버에 대체 데이터베이스 서버의 위치를 설정하면 ACR은 failure 발생시
보조시스템으로 리라우팅할 수 있습니다.
(ACR은 failure가 발생하면 기존 서버에 재접속을 먼저 시도합니다.)
접속이 다시 연결되면, 응용프로그램은 트랜잭션 failure에 관한 오류메시지를 전달받습니다.
하지만 응용프로그램은 작업을 계속하면서 트랜잭션 오류를 프로그램적으로 처리하게 됩니다.
만약 클라이언트 응용프로그램이 DB2 서버로부터 접속을 잃고, 복구 과정에서
보조(alternative) 서버로 투명하게 연결하게 하려면
UPDATE ALTERNATIVE SERVER FOR DATABASE 명령으로 보조 서버의 위치를 지정해 주어야 합니다.
보조 서버 정보는 주 서버에 저장되고 클라이언트가 접속할 때, 클라이언트의 캐시에
저장됩니다. 주 서버에 접속하는데 있어서 DB2 클라이언트를 사용하지 않는 응용프로그램들
(Type4 JDBC를 사용하는 DB2 JDBC Universal Driver를 사용하는 응용프로그램 등)은
보조 서버 정보를 special register에 저장합니다.
UPDATE ALTERNATIVE SERVER FOR DATABASE 명령은 HADR 데이터베이스와도 사용될 수
있습니다. (HADR_REMOTE_HOST , HADR_REMOTE_SVC 파라미터를 사용합니다)
DBA가 특정 데이터베이스와 서버 인스턴스의 보조 서버 위치를 지정하고 나면,
보조 서버 위치는 접속 시에 클라이언트에 전달됩니다. 만약 어떤 이유에서건 접속이
끊어지면 DB2 UDB 클라이언트는 서버에서 받은 보조 서버 정보를 이용하여 접속을
재시도 할 수 있습니다. (물론 기존 서버에 대한 재시도를 먼저 합니다.)
물론 접속 실패(connection failure)가 발생했을 경우 서버 정보가 유지되지 않기 때문에
실행 중에서 롤백된 UOW는 다시 실행 되어야 합니다.
보조 서버 위치는 서버의 시스템 데이터베이스 디렉토리 파일과 클라이언트에서 관리됩니다.
접속시 서버에서 받은 보조 서버 위치 정보 (호스트 이름 또는 IP 주소와 서비스명 혹은
포트번호)는 시스템 데이터베이스 디렉토리 파일에 저장되고 로컬메모리에 캐시됩니다.
서버의 보조 서버 위치가 바뀌면, 클라이언트는 다음 번 접속 때 그 정보를 가져갑니다.
ACR 이 작동하는 방법
시스템 환경이 ACR을 지원한다면, 클라이언트는 기존 서버 위치로 재접속을 시도하고,
보조 서버 위치로도 재접속을 시도하게 됩니다. 만약 다시 접속이 된다면,
SQLCODE-30108(통신 실패 이후 데이터베이스에 다시 접속되었음) 메시지가 내려옵니다.
호스트 이름이나 IP주소 그리고 서비스 명이나 포트번호도 내려옵니다.
클라이언트는 ACR이 기존 통신실패를 복구하는데 실패했을 경우만 해당 에러메시지를 뿌립니다.
ACR - 예제
- DBA가 데이터베이스를 생성하고 UPDATE ALTERNATIVE SERVER FOR DATABASE 명령으로
보조 서버 위치를 업데이트 합니다.
- 원격 데이터베이스가 클라이언트나 LDAP(Lightweight Directory Access Protocol)
디렉토리에 카탈로그 됩니다.
- 클라이언트가 원격 데이터베이스에 접속을 시도합니다.
- 접속 성공 후, 보조 서버 위치는 클라이언트에 전송되고 시스템 데이터베이스 디렉토리와
로컬 디렉토리 캐시에 저장됩니다.
- 응용프로그램이 작업을 수행합니다. 응용프로그램은 데이터베이스와 SQL을 통해
작업을 하고 result set을 클라이언트로 보냅니다.
그러다 INSERT 작업 중 오류가 발생하게 됩니다.
ACR은 메모리에서 보조 서버 위치를 찾아봅니다.
보조 서버 위치가 발견되면 ACR은 우선 접속이 끊긴 이전 서버에 재접속을 시도하고,
이전 서버로의 재접속이 실패하면 보조 서버에 접속을 시도합니다.
- 클라이언트가 보조 서버와 연결됩니다. 트랜잭션은 롤백되었고,
보조서버에서 재실행됩니다.
(프로그램이 이런 에러를 처리하도록 코딩되었을 경우 가능합니다.)
기타 ACR 고려사항
JDBC 드라이버의 경우에는 Type 4 드라이버의 경우에만 보조 서버 위치 정보를 저장할 수
있습니다. alternateDataSource라는 속성을 사용하여 저장됩니다.
저장된 보조 서버 정보는 DB 접속시 서버에서 클라이언트로 동적으로 복사되어, 드라이버의
static 메모리에 보존됩니다.
오류복구 후 재접속이 이루어지면, JDBC 드라이버는 오류복구가 일어났으며 트랜잭션이
실패했다는 내용을 의미하는 SQLCODE-4490과 함께 java.sql.SQLException을 응용프로그램에
보냅니다. 그러면 응용프로그램은 트랜잭션을 복구하고 재시도합니다.
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
