사이트 Failover 및 Recovery

비즈니스에 부정적인 영향을 미칠 일정 기간 동안 기본 사이트를 사용할 수 없고 완전히 액세스할 수 없게 만드는 계획되지 않은 이벤트가 인프라에 발생한 경우 사이트 페일오버가 필요합니다. 이 시나리오에서는 대기 데이터베이스가 기본 역할을 맡습니다.

기본 사이트는 다음을 포함하되 이에 국한되지 않는 다양한 이유로 사용할 수 없게 될 수 있습니다.

실패하거나 광범위하게 손상된 매체, 결함이 있는 OS 또는 펌웨어 업그레이드와 같이 기본 데이터베이스 인스턴스가 시작되지 않도록 만드는 문제
OCI 리전 인프라 내 전체 전원 또는 냉각 시스템 중단과 같은 인프라 장애
네트워크 Failure 완료
지진, 화재, 홍수와 같은 자연재해

계획되지 않은 이벤트는 드물지만 발생할 수 있고 발생할 수 있습니다.

사이트 복구 수행

진정한 페일오버는 중단형이며 일부 데이터 손실이 발생할 수 있으므로 TEST 환경에서 사이트 페일오버를 테스트합니다.

다음 예에서는 애슈번의 기본 데이터베이스(CDBHCM_iad1dx) 및 피닉스의 대기 데이터베이스(CDBHCM_phx5s)에 대한 테스트 환경의 이름을 사용합니다.

기본에서 모든 데이터베이스 Oracle RAC(Oracle Real Application Clusters) 인스턴스를 강제로 정지합니다.

주:
운용 환경에서 이 테스트를 수행하지 마십시오.
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
이 시점부터 기본은 완전히 사용할 수 없는 것으로 간주됩니다(시뮬레이트됨). 우리는 우리의 보조 지역을 우리의 새로운 기본 사이트로 만들 것입니다.
다음 단계에서는 테스트 구현을 사용하고 모든 단계는 보조 사이트(새 기본 사이트)에서 수행됩니다.

보조 사이트에서 Oracle Exadata Database Service on Dedicated Infrastructure domUs 중 하나에 로그인하고 oracle OS 유저로 로그인한 다음 Data Guard Broker 명령행 인터페이스를 호출합니다.

노드: Oracle Exadata Database Service on Dedicated Infrastructure domU
사용자: oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

오류를 확인합니다.

Oracle Data Guard Broker 명령행 인터페이스를 사용하여 failover를 수행합니다.
- 노드: 보조 사이트의 Oracle Exadata Database Service on Dedicated Infrastructure domU 1개
- 사용자: oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
기본 중간 계층(공유 파일 시스템 포함)이 그대로 유지되면 실패한 기본 사이트에서 DR 사이트로 "강제된" rsync를 수동으로 수행합니다.

애플리케이션 및 웹 계층은 여전히 작동하지만 애플리케이션 및 프로세스 스케줄러 프로세스에서 실패한 데이터베이스에 대한 연결을 시도하지 못합니다. 이로 인해 rsync 스크립트가 rsync 수행을 중지합니다.
- 노드: 1개의 중간 계층, 실패한 기본 사이트
- 사용자: psadm2
1. 강제 rsync를 수행합니다. 스크립트 디렉토리에서 샘플 rsync_psft.sh 스크립트를 사용할 수 있습니다.
  rsync 스크립트가 사용 안함으로 설정된 경우 -f 매개변수는 강제 rsync를 사용하여 계속하라는 메시지를 표시합니다. 강제 rsync는 데이터베이스의 롤을 확인하기 위해 데이터베이스를 참조하지 않으며 요청된 rsync를 수행합니다.
  
  주:
  이 작업은 사이트 페일오버 중 최종 새로고침을 강제 수행하는 경우에만 수행해야 합니다. FORCE 옵션을 사용하면 기록됩니다.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  예를 들어 다음과 같습니다.
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. rsync 프로세스 로그를 모니터하여 프로세스가 성공적으로 완료되었는지 확인합니다.
사이트 실패가 완료되었으며 최종 rsync 프로세스를 실행할 수 없는 경우 disable_psft_rsync.sh 스크립트를 실행하여 새 기본 데이터베이스에서 rsync를 사용 안함으로 설정합니다.
- 노드: 1개의 중간 계층, 새로운 기본 사이트
- 사용자: psadm2
```
disable_psft_rsync.sh
```
기본 및 대기 데이터베이스 서버를 구성할 때 Active Data Guard 지원을 구성한 경우 PeopleSoft(PSQUERY)에 대한 Active Data Guard 서비스가 새 기본 데이터베이스에서 시작되었는지 확인합니다.
- 노드: 보조 사이트의 Oracle Exadata Database Service on Dedicated Infrastructure domU 1개
- 사용자: oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
이 서비스는 모든 Oracle RAC(Oracle Real Application Clusters) 인스턴스에서 실행 중이어야 합니다.

주:
프로세스 스케줄러를 시작하기 전에 이 서비스를 시작해야 합니다. 그렇지 않으면 시작 시 프로세스 스케줄러가 실패합니다.
롤 기반 데이터베이스 서비스가 새 기본 데이터베이스에서 작동 중인지 확인합니다.
- 사이트: 사이트 2
- 노드: 모든 Oracle Exadata Database Service on Dedicated Infrastructure domUs
- 사용자: oracle
예를 들어, PeopleSoft Oracle RAC 데이터베이스 인스턴스를 호스팅하는 각 domU에서 다음 명령을 실행합니다.
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
이 서비스는 모든 Oracle RAC 인스턴스에서 실행 중이어야 합니다.

응용 프로그램 서버를 시작하고 스케줄러 도메인을 처리합니다.

사이트: 사이트 2
노드: 애플리케이션 및 프로세스 스케줄러 서버 컴퓨트 인스턴스
사용자: psadm2

PeopleSoft 애플리케이션 서버 및 프로세스 스케줄러를 호스팅하는 컴퓨트 인스턴스에 로그인하여 psadm2로 전환합니다.
GitHub의 래퍼 디렉토리에서 startPSFTAPP.sh 스크립트를 사용합니다.
```
$ startPSFTAPP.sh
```

시작을 모니터합니다.

PeopleSoft 애플리케이션 및 Process Scheduler 도메인에서 질의를 사용할 수 있습니다.

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

5단계에 설명된 대로 전체 사이트 실패가 없는 경우 다음 단계로 이동합니다. 전체 사이트 실패가 발생한 경우 startPSTAPP.sh 스크립트가 rsync를 사용으로 설정하므로 disable_psft_rsync.sh 스크립트를 다시 실행해야 합니다.
주:

기본 사이트가 손실되거나 액세스할 수 없게 되는 실제 실패 이벤트에서는 범위 및 영향에 대한 평가를 수행해야 합니다. 다음은 고려해야 할 몇 가지 항목입니다.
- 데이터베이스 데이터 손실이 발생할 수 있음
- 누락된 파일 시스템 아티팩트(보고서, 로그, 인바운드 및 아웃바운드 파일 등)
정전에 따라 원래 Primary에 커밋된 모든 트랜잭션을 Recovery할 수도 있고 Recovery하지 못할 수도 있습니다. 가능하면 유저에게 자신이 마지막으로 작업한 트랜잭션을 확인하도록 요청합니다.

원본 기본에 대한 액세스가 중단될 때 기록되거나 전송되는 출력에서 누락된 파일 시스템 아티팩트가 있을 수 있습니다. 데이터베이스의 보고서 로깅을 사용하여 운용중단 시점에 생성된 파일 시스템 아티팩트를 식별한 다음, 누락되거나 불완전한 파일에 대해 사례별로 수행해야 하는 작업을 결정합니다.
웹 서비스를 시작합니다.
- 사이트: 사이트 2
- 노드: 모든 PeopleSoft PIA(Internet Architecture) 웹 서버 컴퓨트 인스턴스
- 사용자: psadm2
Coherence*Web이 구성된 경우 먼저 PIA 웹 서버를 호스트하는 모든 컴퓨트 인스턴스에서 캐시 클러스터를 시작한 다음 PIA 웹 서버를 시작합니다. 이 예제에서는 한 스크립트를 사용하여 두 스크립트를 적절한 순서로 시작합니다.
1. PIA 웹 서버에 로그인하여 psadm2로 전환합니다.
2. startPSFTAPP.sh의 스크립트를 사용하여 웹 서버를 시작합니다.
```
$ startPSFTWEB.sh
```
로드 밸런서를 확인합니다.
- 사이트: 지점 2 지역
- 노드: OCI 콘솔
- 사용자: 테넌시 관리자
1. OCI 콘솔에 로그인하여 영역을 새 기본 콘솔로 변경합니다.
2. 기본 메뉴에서 네트워킹, 로드 밸런서를 차례로 선택합니다.
3. 적절한 구획을 선택합니다.
4. 백엔드 집합, 백엔드를 차례로 누릅니다.
  각 백엔드에는 OK가 표시되어야 합니다. 각 PIA 웹 서버가 시작된 후 몇 분 정도 걸릴 수 있습니다.

실패한 기본을 새 대기로 복원

standby site를 사용하여 새 운용 환경을 보호해야 합니다. 이상적으로는 데이터베이스와 파일 시스템을 모두 복원하여 실패한 기본 데이터베이스를 새 대기 데이터베이스로 복원할 수 있습니다.

이전 Primary Database를 Standby로 복원

Oracle Data Guard는 기본 사이트 실패 후 다시 사용할 수 있게 되면 이전 기본 데이터베이스가 열리지 않도록 합니다. 데이터베이스를 정상적으로 시작하려고 시도하면 실패하고 복원이 필요함을 나타내는 메시지가 경보 로그에 기록됩니다. 실패 전에 이 데이터베이스에서 Flashback Database를 활성화한 경우 이전 기본 데이터베이스를 새 대기 데이터베이스로 복원할 수 있습니다.

다음을 수행하여 이전 primary를 현재 운용 중인 standby database로 복원합니다.

이전 primary database를 호스팅하는 domUs 중 하나에 로그인하고 데이터베이스를 시작합니다.
```
$ srvctl start database -db CDBHCM_phx5s
```

새 기본 영역에서 Data Guard Broker 명령행 인터페이스에 로그인하여 구성을 표시합니다.

아래 굵게 표시된 ORA-16661 오류를 살펴봅니다.

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

standby site를 복원합니다.
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
주:
실패한 데이터베이스를 recovery하고 적합한 standby database를 시작하는 프로세스는 완료하는 데 시간이 걸릴 수 있습니다.
Data Guard 중계자 명령행 인터페이스를 사용하여 환경의 상태를 확인합니다.
예를 들어 다음과 같습니다.
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
이제 복원된 데이터베이스가 대기 데이터베이스로 사용되어 기본 데이터베이스를 보호하고 스위치오버 및 페일오버에 사용할 수 있습니다.

기본 및 대기 데이터베이스 서버를 구성할 때 Active Data Guard 지원을 구성한 경우 PeopleSoft(PSQUERY)에 대한 Active Data Guard 서비스를 기본 데이터베이스에서 다시 대기 데이터베이스로 재배치할 수 있습니다.

이전 기본 중간 계층을 대기로 복원

페일오버 이벤트를 기반으로 이전 기본 중간 계층을 복원합니다.

데이터베이스 복구 이벤트가 발생한 동안 이전 기본 중간 계층 서버를 사용 가능한 상태로 유지한 경우 실패 시 실패한 기본 사이트에서 대기 사이트로 최종 강제 rsync를 수행한 다음 스위치오버를 수행할 때와 동일한 방식으로 rsync 프로세스의 방향을 반대로 바꿨어야 합니다.

애플리케이션 및 웹 계층은 여전히 작동하지만 애플리케이션 및 프로세스 스케줄러 프로세스에서 실패한 데이터베이스에 대한 연결을 시도하지 못합니다. 이로 인해 rsync 스크립트가 rsync 수행을 중지합니다.
1. 공유 파일 시스템을 포함한 기본 중간 계층이 그대로 유지되면 실패한 기본 사이트에서 DR 사이트로 "강제된" 재동기화를 수동으로 수행합니다.
  rsync 스크립트가 사용 안함으로 설정된 경우 -f 매개변수는 강제 rsync를 사용하여 계속하라는 메시지를 표시합니다. 강제 rsync는 데이터베이스의 롤을 확인하지 않고 요청된 rsync를 수행합니다.
  
  주:
  이 작업은 사이트 페일오버 중 최종 새로고침을 강제 수행하는 경우에만 수행해야 합니다. FORCE 옵션을 사용하면 기록됩니다.
  
  스크립트 디렉토리 rsync_psft.sh의 샘플 스크립트를 사용자 psadm2로 사용할 수 있습니다.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  예를 들어 다음과 같습니다.
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. rsync 프로세스 로그를 모니터하여 프로세스가 성공적으로 완료되었는지 확인합니다.
rsync에서도 이전 기본 사이트에 완전히 액세스할 수 없는 경우 다음을 수행합니다.
1. 복제 중인 모든 파일 시스템에 대해 disable_psft_rsync.sh를 사용하여 새 기본 사이트에서 rsync 스크립트를 사용 안함으로 설정합니다.
2. 나중에 원래 중간 계층에서 작업을 재개할 수 있는 경우 rsync 스크립트를 다시 사용으로 설정하고 이를 따라잡도록 합니다.
중간 계층을 재구축해야 하는 경우 앞에서 설명한 프로세스를 따릅니다.