구성 확인

DR 설정이 완료되면 즉시 완전한 스위치오버를 수행하거나 보조 사이트에서 검증을 열어 설정이 올바른지 검증합니다. 검증을 위해 보조 사이트를 열면 주 사이트에서 실행 중인 시스템에 영향을 주지 않습니다.

검증을 위해 보조 열기

standby database를 snapshot standby로 변환하여 complete switchover를 수행하지 않고 standby 사이트를 검증할 수 있습니다. 이렇게 하면 보조 WebLogic Server 서버를 대기 사이트에서 시작하고 보조 시스템을 확인할 수 있습니다. {\f2732 snapshot standby }모드일 때{\f2732 standby }사이트 데이터베이스에서 수행된 모든 변경 사항은 물리적{\f2732 standby database}로 다시 변환되면 폐기됩니다{\f2732 .} 기본 데이터가 보조 사이트 검증의 영향을 받지 않습니다.

참고:

이 작업은 주의해서 수행해야 합니다. 스냅샷으로 변환될 때 데이터베이스에 보류 중인 JMS 메시지가 있으면 대기 사이트의 서버가 시작 시 해당 메시지를 처리합니다. Snapshot Standby로 변환할 때 Primary Database에 보류 중인 작업이 없는지 확인합니다.

oracle 유저로 primary db 호스트에서 Oracle Data Guard broker를 사용하여 보조 데이터베이스를 snapshot standby로 변환합니다.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
show configuration 명령을 사용하여 변환이 올바르게 수행되었는지 확인합니다.
아직 작동 중이지 않은 경우 보조 사이트에서 Oracle HTTP Server 시스템을 시작합니다.
보조 사이트에서 관리 서버를 시작합니다.
보조 사이트에서 보조 관리 서버를 시작합니다.
WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.
보조 사이트를 검증합니다.

이 이름은 스위치오버가 아니며 기본 사이트가 여전히 활성 상태이므로, 가상 프론트 엔드 이름은 기본 사이트의 로드 밸런서 IP 주소로 확인되므로 모든 브라우저 액세스는 기본적으로 활성 기본 사이트로 재지정됩니다.

보조 사이트의 WebLogic 서버 응용 프로그램에 직접 액세스하려면 제어된 클라이언트(예: 랩탑)에서 /etc/hosts 파일을 업데이트하고, 보조 사이트의 프론트 엔드 로드 밸런서 IP 주소로 분석하도록 가상 프론트 엔드 이름을 설정하고, 이 클라이언트에서 검증을 실행해야 합니다.

참고:
HTTP 프록시가 클라이언트의 /etc/hosts에 있는 이름에 관계없이 기본 사이트의 로드 밸런서 IP 주소로 가상 프론트 엔드 이름을 계속 확인할 수 있으므로 검증에 사용된 클라이언트가 HTTP 프록시를 통해 시스템에 액세스하지 않는지 확인합니다.

비Linux 클라이언트는 브라우저에서 사용자 정의된 호스트 파일 항목을 사용하여 IP 주소를 확인하기 전에 로컬 DNS 캐시를 재설정해야 할 수 있습니다.

보조 사이트가 검증되면 다음 단계로 이동하여 대기 역할로 되돌립니다.

참고:
보조 사이트를 검증하는 데 시간이 걸릴 수 있습니다.
보조 사이트에서 관리되는 서버 및 관리 서버를 중지합니다.
보조 WebLogic 콘솔을 사용하여 보조 사이트에서 관리 서버 및 관리 서버를 종료합니다.
oracle 유저로 primary 데이터베이스 호스트에서 Oracle Data Guard broker를 사용하여 보조 데이터베이스를 다시 물리적 standby로 변환합니다.
시스템 비밀번호와 기본 데이터베이스의 고유한 이름이 필요합니다.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
show configuration를 사용하여 변환을 확인합니다.
업데이트된 /etc/hosts 파일을 되돌립니다.
검증을 위해 보조 사이트를 가리키도록 클라이언트의 /etc/hosts 파일을 업데이트한 경우 가상 프론트 엔드 이름이 기본 프론트 엔드 IP 주소를 다시 가리키도록 되돌립니다.

Switchover 수행

전환은 관리자가 두 사이트의 롤을 되돌리는 계획된 작업입니다. 스위치오버 후에 기본 시스템은 보조 시스템이 되고 보조 시스템은 기본 시스템이 됩니다. switchover를 수행하면 기본 사이트에서 작동 중지 시간이 발생합니다.

WebLogic Server 하이브리드 DR 구성에서 스위치오버를 수행하기 전에 보류 중인 구성 변경 사항을 전파합니다. 보류 중인 보조 사이트에 복제된 변경사항이 없는지 확인합니다.

스위치오버가 수행되는 동안 예약된 복제를 사용 안함으로 설정합니다. 실패하고 스위치오버 작업 자체를 방해할 수 있기 때문입니다.
기본 사이트에서 Oracle HTTP Server 시스템을 정지합니다.
기본 사이트에서 서버를 중지합니다.
WebLogic 관리 서버 콘솔 또는 스크립트를 사용하여 기본 사이트에서 WebLogic 서버를 정지합니다.

참고:
기본 사이트의 관리 서버는 스위치오버 중 작동 상태로 유지될 수 있습니다. 하지만 사이트가 대기 롤인 경우에는 대기 사이트의 도메인 구성이 수명 주기 동안 기본 구성으로 무효화될 것으로 예상되므로 정지하는 것이 좋습니다. 이 작업이 수행되는 동안 관리 서버가 작동 중인 경우 사용되지 않는 구성으로 실행됩니다.
프론트 엔드 DNS 이름을 스위치오버합니다.

시스템에서 사용하는 이름을 호스트하는 DNS 서버에서 필요한 DNS 푸시를 수행하거나 클라이언트의 파일 호스트 확인을 변경하여 시스템의 프론트엔드 가상 이름을 보조 사이트의 로드 밸런서가 사용하는 공용 IP로 가리킵니다.

DNS가 외부 프런트엔드 분석(예: OCI DNS 또는 상용 DNS)에 사용되는 시나리오의 경우 API를 사용하여 변경 사항을 푸시할 수 있습니다. OCI DNS에서 이 변경사항을 푸시하는 예를 보려면 GitHub(예: 스크립트)로 이동하십시오.

DNS 항목의 TTL 값은 스위치오버의 RTO에 영향을 줍니다. TTL이 높을 경우(예: 20분), DNS 변경은 클라이언트에서 적용하는 데 시간이 걸립니다. 낮은 TTL 값을 사용하면 속도가 빨라지지만 이로 인해 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하므로 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS가 변경되기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경을 수행하고 switchover 프로시저가 완료되면 TTL을 다시 원래 값으로 되돌립니다.
oracle 유저로 primary database 호스트에서 Oracle Data Guard broker를 사용하여 데이터베이스 switchover를 수행합니다.
시스템 비밀번호와 기본 데이터베이스의 고유한 이름이 필요합니다.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
보조 사이트(새 기본 사이트)에서 관리 서버를 시작하거나 이미 시작된 경우 서버를 재시작합니다.
Admin Server를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
보조 사이트(새 기본 사이트)에서 보조 관리 서버를 시작합니다.
WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.