반응형

9. Transparent Application Failover(TAF) 테스트

   

※ Oracle TAF는 데이터베이스 연결에 장애가 발생한 경우 클러스터의 다른 노드로 재연결하기 위한 페일오버 메커니즘을 제공합니다.

    페일오버 과정은 사용자 관점에서 투명하게 수행됩니다. 오라클은 페일오버된 인스턴스에서 쿼리를 재실행하고 결과를 사용자에게

    반환합니다.

※ 테스트를 수행하기에 앞서 발생한 문제 먼저 해결 하겠습니다. 저같은 경우 모든 설치를 마치고 TAF 테스트는 다음 날 수행했는데

    컴을 껐다 키니까 애플리케이션 리소스가 실행 되어 있지 않았습니다. 간단한 절차지만 애플리케이션 리소스 실행하고 상태먼저 확인

    하고 시작하겠습니다.

   

(crs_stat 수행 해 보니 rac1 노드의 리소스만 ONLINE 상태임을 알 수 있다.)

   

   

(상태확인을 함에 있어서도 깔끔하지 않고 찝찝하기 짝이없다 ㅋㅋ)

   

이제 애플리케이션 리소스 시작시키자!! oracle 계정으로 수행^^

   

srvctl stop instance -d devdb -i devdb1

     srvctl stop asm -n rac1

     srvctl stop nodeapps -n rac1

   

     srvctl start instance -d devdb -i devdb1

     srvctl start asm -n rac1

     srvctl start nodeapps -n rac1

   

srvctl stop instance -d devdb -i devdb2

     srvctl stop asm -n rac2

     srvctl stop nodeapps -n rac2

   

     srvctl start instance -d devdb -i devdb2

     srvctl start asm -n rac2

     srvctl start nodeapps -n rac2

   

       devdb : database name

                    devdb1/devdb2 : instance name

     rac1/rac2 : hostname

   

   

(rac1 뿐 아니라 rac2 의 애플리케이션 리소스들도 ONLINE 상태가 됬다.)

   

   

(이 얼마나 깔끔하고 아름다운 광경인가...ㅋㅋㅋㅋㅋ)

   

   

     9-1. 새로운 데이터베이스 서비스의 생성

   

자!! 이제 본론으로 들어가 보겠습니다~~~~~ 라고 이야기 했습니다만 새로운 DB 생성을 위해 DBCA를 실행한 순간 또

다시 DISPLAY 에러 강림하심...

   

   

(앞서 설명한데로 root 계정으로 # xhost + 실행하고 oracle 계정으로 export DISPLAY=:0.0 실행 후 dbca 실행)

   

   

(짜잔~~~^^ 이제 본격적으로 시작!! Oracle Real Application Cluster database 선택 후 Next)

   

   

(Services Management 선택 후 Next)

   

   

(Next)

   

   

(Add를 클릭하고 서비스 추가하자)

   

   

   

(Add a Service에 CRM 이라고 입력하고 OK)

   

   

(devdb1은 Preferred 선택, devdb2는 Available 선택, TAF Policy는 Basic 선택 후 Finish~)

   

   

   

(OK~~)

   

   

(Service 설치 중~)

   

   

(다른 거 설치할 것 없으니까 No~~클릭)

   

   

   

(tnsnames.ora 파일에 위와 같이 CRM 네임 엔트리를 생성한 것을 알 수 있다.)

   

   

   

(CRM이 devdb1 인스턴스에 붙어 있다. devde1에서 장애 발생시 CRM이 devdb2에 붙게 된다. 잠시후 확인)

   

   

   

     9-2. CRM 서비스를 이용하여 첫 번째 세션에 연결

   

   

(CRM이 devdb1에 붙어있고, failover 방식은 Basic 이며 fail over는 발생하지 않았음을 알 수 있다.)

   

   

     9-3. 다른 세션에서 인스턴스를 셧다운

   

   

(새로운 터미널을 열고 위와 같이 장애상황 발생 설정)

   

   

   

     9-4. 세션이 페일오버 되었는지 확인

   

   

(CRM이 devdb2에 붙었고 failed_over 컬럼이 YES 즉, fail over가 수행 되었음을 확인 할 수 있다.)

   

   

     9-5. CRM 서비스를 preferred instance로 페일백

   

※ devdb1이 다시 시작된 이후에도 CRM 서비스는 preferred instance로 페일백 처리되지 않습니다. 따라서 수동으로 서비스를

    devdb1으로 이전해 주어야 한다.

   

   

(rac2 노드의 devdb2 인스턴스에 붙어있는 CRM!!)

   

   

   

(위와 같이 rac1-> srvctl relocate service -d devdb -s crm -i devdb2 -t devdb1 명령어로 페일백 시켜준다.)

   

   

(다시 devdb1으로 컴백한 CRM을 확인!!)

   

   

   

 

출처 : http://blog.naver.com/chosuky?Redirect=Log&logNo=100091891048 [출처] VMware를 이용한 Oracle Enterprize Linux에 Oracle RAC 10g 설치(5)|작성자 초수키

[출처] VMware를 이용한 Oracle Enterprize Linux에 Oracle RAC 10g 설치(5)|작성자 초수키

반응형

+ Recent posts