Oracle 데이터베이스 워크로드의 재해 복구 옵션
이 가이드에서는 베어메탈 솔루션 환경에서 비즈니스 관련 중요한 Oracle 데이터베이스 워크로드를 실행하는 사용자가 사용할 수 있는 재해 복구 옵션을 설명합니다.
이 가이드에서는 Oracle Enterprise Edition을 실행한다고 가정합니다. 이 가이드에 설명된 일부 기능은 Enterprise Edition 라이선스 외부에 별도로 라이선스가 부여됩니다. 이러한 기능에는 다음이 포함되나 이에 국한되지 않습니다.
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Oracle 라이선스 계약을 참고하여 재해 복구 및 고가용성 계획을 수립할 때 사용할 수 있는 기능을 확인하세요.
애플리케이션 RTO 및 RPO
Oracle 데이터베이스 기술의 재해 복구는 애플리케이션의 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)를 기반으로 결정해야 합니다. 일반적으로 RTO는 시스템에 허용되는 다운타임 시간을 나타내고 RPO는 허용되는 데이터 손실 양을 나타냅니다. 이러한 각 값이 감소할수록 시스템의 비용과 복잡성은 증가합니다. RTO 및 RPO에 대한 자세한 내용은 DR 계획의 기초를 참조하세요.
'RPO = 0' 또는 '데이터 손실 없음'으로 라벨이 지정된 아키텍처의 경우 데이터가 데이터베이스에 '커밋'되었다고 간주되기 전에 여러 위치에 데이터를 써야 합니다. RPO가 0에 가까워질수록 지연 시간이 문제가 됩니다.
설계 단계에서 제대로 고려하지 않으면 데이터 손실 제로 아키텍처를 구현하면 전반적인 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다.
고가용성과 재해 복구 비교
고가용성과 재해 복구는 안정적인 데이터베이스 아키텍처를 설계할 때 상호 보완적인 개념입니다. 이 가이드의 맥락에서 고가용성은 시스템의 개별 또는 연쇄 장애로부터 자동으로 복구하는 시스템의 기능을 의미합니다. 반면에 재해 복구는 전반적인 업무 연속성 계획의 일부이며 전체 시스템 그룹을 사용할 수 없게 만들 수 있는 더 큰 규모의 장애에 적용됩니다. 재해 복구는 재해 발생 시 복구해야 하는 통합 구성요소의 수로 인해 더 큰 범위를 포함합니다.
안정적인 시스템을 설계할 때는 고가용성을 '최초 방어선'으로 간주해야 합니다. 고가용성 데이터베이스 아키텍처는 개별 장애를 견뎌내고 애플리케이션의 다운타임을 일으키지 않고 계속 실행할 수 있어야 합니다. 시스템의 고가용성 구성요소에는 다음이 포함되지만 이에 국한되지 않습니다.
- 서버, 네트워크 또는 스토리지 하드웨어에 예비 전원 공급
- 다중 네트워크 인터페이스, 스위치, 케이블
- 중복 스토리지 패브릭, 컨트롤러, 디스크 기기
- Google Cloud와 베어메탈 솔루션 리전 확장 프로그램 간의 내결함성 Partner Interconnect
- 서버 오류로 인해 데이터베이스가 사용 중지되지 않도록 하는 Oracle RAC
재해 복구 설계에는 구성요소를 사용할 수 없게 만드는 여러 연쇄 장애로부터 복구하는 프로세스가 포함되어야 합니다. 재해 복구 계획을 수립할 때는 다음 사항을 고려해야 합니다.
- 리전 서비스 중단
- 자연 재해
- 애플리케이션의 구성요소 하나 이상이 완전히 중단되는 이슈
Oracle 재해 복구 및 고가용성 도구
다음은 Oracle 재해 복구 및 고가용성 도구입니다.
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- 플래시백 데이터베이스
- Oracle GoldenGate
Oracle Real Application Clusters
Oracle Real Application Clusters(RAC)는 여러 데이터베이스 서버에서 처리할 데이터베이스 워크로드를 수평 확장하는 데 사용됩니다. RAC를 사용하는 데이터베이스는 리전 확장 내 서버 간에 활성/활성 구성을 허용합니다.
RAC는 일반적으로 단일 서버 장애로부터 보호해야 하는 시스템에 고가용성을 제공하는 데 사용됩니다. 클러스터링에 '모든 항목 공유' 접근 방식(공유 스토리지 및 공유 네트워크)을 사용하기 때문에 베어메탈 솔루션 환경에서 실행되는 RAC 클러스터는 단일 베어메탈 솔루션 포드 내에 있어야 합니다. 따라서 RAC는 고가용성 문제를 해결하는 솔루션이지만 재해 복구 요구사항은 해결하지 못합니다.
베어메탈 솔루션용 RAC를 설정하는 방법을 알아보려면 베어메탈 솔루션에 Oracle RAC 설치를 참조하세요.
Oracle Recovery Manager
Oracle Recovery Manager(RMAN)는 Oracle의 독점 데이터 파일 형식을 읽을 수 있는 기능이 있어 Oracle 데이터베이스의 백업 및 복구를 위한 기본 도구입니다. Oracle 데이터베이스 내에서 데이터베이스 클론, PITR(point-in-time recovery) 또는 단일 테이블 복구를 수행하는 데 사용할 수 있습니다.
RMAN은 데이터베이스가 열려 있는 동안 백업을 수행하는 데 사용할 수 있는 유일한 도구입니다. 복구에 사용할 수 있는 백업 파일의 카탈로그를 유지하는 데도 사용됩니다.
Oracle Data Guard
Oracle Data Guard는 원격 RAC 클러스터 또는 기타 데이터베이스 설치로 데이터베이스 복제를 실행합니다. Data Guard는 물리적 또는 논리적 구성에서 대기 데이터베이스를 지원합니다.
물리적 대기 데이터베이스는 블록 단위의 사본으로, 데이터베이스의 한 사본만 쓰기를 위해 열어 둡니다. 다른 모든 사본은 마운트(열지는 않음)하여 변경사항을 적용하거나 읽기 전용으로 열어 보고 애플리케이션을 지원합니다.
베어메탈 솔루션에서 Data Guard를 설정하는 방법을 알아보려면 베어메탈 솔루션에 Oracle Data Guard 배포를 참조하세요.
FLASHBACK DATABASE
Oracle Enterprise Edition의 FLASHBACK DATABASE 기능을 사용하면 관리자가 시간이 많이 소요되는 데이터베이스 복원을 실행하지 않고도 데이터베이스를 특정 시점으로 빠르게 되돌릴 수 있습니다.
재해 복구 컨텍스트에서 FLASHBACK DATABASE는 일반적으로 데이터베이스 복구를 더 빠르게 하기 위해 장애 조치 작업 중에 Data Guard와 함께 사용됩니다. 실패한 데이터베이스는 새 기본의 로그와 일치하는 특정 시점으로 다시 플래시되고 완전히 다시 동기화할 수 있도록 재실행이 전송됩니다.
Oracle GoldenGate
Oracle GoldenGate는 활성/활성 멀티 사이트 배포를 사용 설정하거나 하드웨어 플랫폼 간에 데이터를 이동하는 데 일반적으로 사용되는 논리적 복제 도구입니다. GoldenGate를 사용하는 경우 소스 데이터베이스의 extract 프로세스가 온라인 재실행 로그의 변경사항을 캡처하여 트레일 파일의 변경사항에 기록하고, 이러한 변경사항은 대상 데이터베이스로 전송됩니다. 대상 데이터베이스의 replicat 프로세스는 트레일 파일의 트랜잭션을 SQL로 변환하고 대상 데이터베이스에서 SQL을 실행합니다.
이 아키텍처를 사용하면 GoldenGate를 데이터베이스 플랫폼 간에 데이터를 이동하거나 데이터가 복제될 때 데이터를 변환하는 강력한 도구로 사용할 수 있습니다. Data Guard와 달리 GoldenGate는 소스 시스템과 대상 시스템에 별도의 소프트웨어를 설치하고 유지해야 합니다. 트랜잭션이 대상 데이터베이스에서 SQL로 변환되고 적용되므로 GoldenGate는 동기 복제에 사용할 수 없습니다. GoldenGate는 복제에 최소 지연을 제공할 수 있지만 GoldenGate만으로는 RPO 0을 보장할 수 없습니다.
재해 복구 배포 모델(데이터베이스 전용)
Oracle은 애플리케이션 및 데이터베이스 배포를 위한 권장 재해 복구 모델을 제공하기 위해 최대 가용성 아키텍처(MAA) 프레임워크를 만들었습니다.
다음 모델은 각각 구체적인 RTO 및 RPO 타겟을 제공합니다.
모델은 계획된 서비스 중단 및 계획되지 않은 서비스 중단 이벤트에서 RPO 및 RTO를 충족하는 특정 배포 패턴에 매핑됩니다. 각 데이터베이스 워크로드는 가용성 요구사항에 대해 평가되고 상응하는 모델로 설계되어야 합니다. 개발 데이터베이스는 프로덕션 및 QA 데이터베이스보다 보호 수준이 낮은 모델을 사용하는 것이 일반적입니다.
브론즈 모델은 분 단위로 측정되는 RTO가 필요하지 않은 데이터베이스를 위해 설계되었습니다. 실버 이상 등급 모델에는 원격 사이트에서 실행되는 대기 데이터베이스가 포함됩니다. 각 모델은 하위 수준 모델의 기능을 통합합니다. 예를 들어 브론즈 모델은 대기 데이터베이스가 배포된 경우에도 계속 따라야 하는 백업 및 복구 개념을 사용합니다.
코퍼 모델
코퍼 모델은 데이터베이스를 로컬 스토리지 미디어에 백업하고 리전 확장 외부에 있는 스토리지에 복사하는 최소한의 배포를 제공합니다. 이 배포에는 두 단계 접근 방식이 필요하지만 Google Cloud SDK를 사용하여 백업 전송을 자동화하도록 스크립트할 수 있습니다.
또한 이 배포를 사용하면 필요한 두 단계 복구로 인해 RTO가 증가합니다. RMAN은 백업에 직접 액세스할 수 없으므로 복구를 시작하려면 백업을 RMAN에서 사용할 수 있는 위치로 이동해야 합니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간 |
| 재해: 손상 | 리전 확장 외부로 전송된 마지막 보관 로그, 증분 백업 또는 전체 백업 | Partner Interconnect에 할당된 데이터베이스 크기 및 대역폭에 따라 몇 시간 | |
| 재해: 리전 확장 실패 | 리전 확장 외부로 전송된 마지막 보관 로그, 증분 백업 또는 전체 백업 | 리전 확장을 다시 온라인으로 가져오는 데 필요한 시간에 따라 며칠/몇 주 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간 |
브론즈 모델
브론즈 모델은 두 가지 배포 옵션을 제공합니다. 두 옵션 모두 데이터베이스 백업을 보관하기 위해 Google Cloud 기반 스토리지를 사용합니다.
브론즈 배포 1: Regional Storage에 백업
이 배포에서는 백업이 오프사이트 미디어에 직접 기록됩니다. 대부분의 경우 Cloud Storage 버킷을 파일 시스템으로 제공하는 Cloud Storage FUSE가 포함된 Cloud Storage가 기본 백업 대상입니다.
Cloud Storage FUSE 사용 권장사항은 NFS 및 Cloud Storage를 사용한 Oracle 백업에서 확인할 수 있습니다. 베어메탈 솔루션 인스턴스에 NFS 공유를 제공하는 Google Cloud Filestore도 사용할 수 있습니다.
다음 다이어그램은 배포의 예시를 보여줍니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간 |
| 재해: 손상 | 마지막 보관 로그, 증분 백업 또는 전체 백업 | Partner Interconnect에 할당된 데이터베이스 크기 및 대역폭에 따라 몇 시간 | |
| 재해: 리전 확장 실패 | 마지막 보관 로그, 증분 백업 또는 전체 백업 | 리전 확장을 다시 온라인으로 가져오는 데 필요한 시간에 따라 며칠/몇 주 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간 |
브론즈 배포 2: 백업 및 DR을 사용한 백업
이 배포에서는 백업 및 DR 서비스를 사용하여 Google Cloud에 백업을 저장합니다. 백업 및 DR은 백업에 영구 증분 접근 방식을 제공하며, 장기 보관을 위해 Cloud Storage의 지원을 받는 고성능 미디어에 저장됩니다.
또한 백업 및 DR은 Filestore 또는 Cloud Storage에 백업을 저장하는 것보다 더 빠른 RTO를 제공합니다. Oracle 인스턴스에서 데이터베이스 파일의 이미지를 즉시 사용할 수 있기 때문입니다. 마운트 및 마이그레이션 기능은 프로덕션 스토리지 미디어로 다시 복사하면서 데이터베이스를 빠르게 온라인으로 가져와 RTO를 대폭 줄입니다.
다음 다이어그램은 배포의 예시를 보여줍니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 재해: 손상 | 마지막 보관 로그, 증분 백업 또는 전체 백업 | 성능 요구사항, 데이터베이스 크기, Partner Interconnect에 할당된 대역폭에 따라 수 분에서 수 시간 | |
| 재해: 리전 확장 실패 | 마지막 보관 로그, 증분 백업 또는 전체 백업 | 지역 확장을 다시 온라인으로 가져오는 데 필요한 시간 또는 고객이 다른 지역 확장으로 이동 가능 여부에 따라 며칠/몇 주 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간 |
실버
실버 모델에서는 Oracle Data Guard를 사용한 데이터베이스 복제를 도입합니다. Data Guard는 대기 데이터베이스로 작동하는 하나 이상의 데이터베이스를 사용하여 실시간 데이터베이스 복제를 제공합니다. Data Guard는 데이터베이스 변경사항이 발생할 때마다 전송하고 적용하는 것을 사용하므로 RPO가 거의 0에 가까울 수 있습니다. 실버 모델은 비동기 복제를 사용합니다. 동기식 복제를 사용하면 데이터 손실이 없지만 리전 간에 데이터를 전송하는 데 걸리는 시간으로 인해 일반적으로 애플리케이션 응답 시간이 허용 가능한 한도를 초과합니다.
Data Guard의 빠른 시작 장애 조치 기능은 사용자가 정의한 기간 동안 기본 데이터베이스를 사용할 수 없게 된 경우 자동 장애 조치 작업을 수행할 수 있는 기능을 제공합니다. 구성은 실행할 수 있는 Data Guard 관찰자 프로세스에 의해 모니터링됩니다.
실버 모델은 전체 지역 장애 발생 시 데이터베이스를 사용할 수 있다는 이점이 있지만 애플리케이션 서버와 데이터베이스 간의 네트워크 지연 시간이 증가함에 따라 장애 조치 및 전환 작업이 애플리케이션 성능에 영향을 줄 수 있습니다. 애플리케이션과 지원 데이터베이스를 서로 다른 리전에서 실행하는 것은 거의 권장되지 않습니다. 데이터베이스의 RTO는 1분 미만일 수 있지만 애플리케이션 장애 조치의 경우 서비스가 완전히 작동하기까지 수 분에서 수 시간이 걸릴 수 있습니다. 대부분의 경우 리전 간 재해 복구 장애 조치 계획을 실행할 때는 이동하는 구성요소의 수가 많기 때문에 일반적으로 수동 프로세스가 필요합니다.
실버 모델에서는 분기별 패치 활동 중에 다운타임 또는 유지보수 기간이 발생할 수 있습니다. Oracle RAC를 도입하면 패치 또는 서버 오류로 인한 다운타임을 줄일 수 있습니다.
다음 다이어그램은 구성의 예시를 보여줍니다.
다이어그램의 구성 예시는 us-west2 및 us-east4 리전에서 실행되는 RAC 데이터베이스를 보여줍니다. 비동기 Data Guard를 사용하여 복제를 구성합니다. 베어메탈 솔루션과 Google Cloud 간의 모든 트래픽은 Partner Interconnect를 통과하며, 리전 간 트래픽은 Google 네트워크 백본을 통해 이동합니다. 애플리케이션 서버는 각 리전에서 구성되지만 일반적으로 장애 조치 이벤트가 선언될 때까지 재해 복구 리전에서 종료됩니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 재해: 손상 | 60초 미만 | 애플리케이션 장애 조치에 따라 수 분에서 수 시간 | |
| 재해: 리전 확장 실패 | 60초 미만 | 애플리케이션 장애 조치에 따라 수 분에서 수 시간 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간
|
골드 모델
실버 모델의 데이터 손실이 우려되는 경우 원격 동기화 인스턴스를 사용하여 Google Cloud Compute Engine에서 실행되는 인스턴스에 동기식 복제를 제공하는 골드 모델을 선택할 수 있습니다.
원격 동기화 인스턴스에는 데이터베이스 제어 파일과 기본 데이터베이스 근처에서 지리적으로 실행되는 대기 재실행 로그 세트가 포함됩니다. 이 인스턴스는 짧은 지연 시간으로 동기식으로 재실행을 수신하도록 구성되어 모든 변경사항을 기본 데이터베이스의 리전 확장 외부에 기록할 수 있습니다. 그런 다음 원격 동기화 인스턴스는 원격 리전의 대기 데이터베이스에 재실행을 전달하여 비동기식으로 적용합니다.
원격 동기화 인스턴스는 데이터베이스의 전체 사본이 아니므로 애플리케이션 트래픽을 처리할 수 없습니다. 원격 동기화 인스턴스는 데이터베이스 변경사항을 동기식으로 쓸 수 있는 내결함성 위치를 제공하여 데이터 손실이 없는 솔루션을 제공하는 데 사용됩니다. 원격 동기화 인스턴스에 동기 복제를 실행할 때는 변경사항이 원격 동기화 인스턴스에서 수신되고 커밋될 때까지 기본 데이터베이스에서 트랜잭션이 커밋되지 않습니다.
Compute Engine 인스턴스는 일반적으로 원격 동기화 인스턴스 호스팅 후보로 선택됩니다. 원격 동기화 인스턴스를 기본 데이터베이스와 가까운 Compute Engine 영역에 배치하면 최소 지연 시간(일반적으로 1.5ms 미만)이 추가되고 리전 확장 내에서 장애가 발생하지 않도록 보호할 수 있습니다.
다음 다이어그램은 배포의 예시를 보여줍니다.
다이어그램의 예시 구성은 Compute Engine에서 실행되는 애플리케이션과 함께 us-west2에서 실행되는 기본 RAC 데이터베이스를 보여줍니다. us-west2 내의 Compute Engine 인스턴스가 원격 동기화 인스턴스를 실행하고 동기식 재실행을 수신합니다. 원격 동기화 인스턴스는 us-east4 리전에서 실행되는 RAC 데이터베이스에 재실행을 비동기식으로 전송하도록 구성됩니다. 애플리케이션 인스턴스는 재해 발생 시 애플리케이션 트래픽을 처리하도록 Compute Engine의 us-east4 리전에 구성됩니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 재해: 손상 | 0 | 애플리케이션 리전 장애 조치에 따라 수 분에서 수 시간 | |
| 재해: 리전 확장 실패 | 0 | 애플리케이션 리전 장애 조치에 따라 수 분에서 수 시간 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간
|
플래티넘 모델
플래티넘 모델은 두 가지 배포 옵션을 제공합니다. 각 배포 옵션은 서로 다른 기술을 사용하여 보호 기능을 제공하며 서로 다른 RTO 및 RPO 특성을 보유합니다.
플래티넘 배포 1: 빠른 시작 장애 조치가 있는 Data Guard
플래티넘 배포 1은 Compute Engine 인스턴스에서 실행되는 로컬 리전에 두 번째 Data Guard 대기 데이터베이스를 추가하여 골드 모델 배포를 기반으로 합니다. 이 구성은 Compute Engine에서 실행되는 기본 데이터베이스와 대기 데이터베이스 간의 동기식 복제를 사용하여 기본 리전 내에서 데이터 손실이 없음을 보장합니다.
리전 내 대기 데이터베이스를 만들면 애플리케이션에 영향을 주지 않고 데이터베이스 장애 조치 및 전환 작업을 수행할 수 있습니다. 데이터베이스 역할이 변경되는 동안 Oracle의 클라이언트 고려사항에 따라 구성된 애플리케이션은 수동 개입 없이 새 기본 데이터베이스에 자동으로 다시 연결됩니다. 올바르게 구성된 애플리케이션의 경우 장애 조치 이벤트 중에 다운타임이 2분 미만입니다.
Compute Engine의 대기 데이터베이스는 RAC를 실행하지 않지만 기본 데이터베이스로 실행될 때 일반 애플리케이션 트래픽을 지원할 수 있도록 크기를 조정해야 합니다. 이 인스턴스는 대기 모드로 작동하는 동안 더 작은 형태로 실행되고 장애 조치 이벤트 중에 확장되거나 항상 전체 용량으로 실행될 수 있습니다. 크기 조절 작업 중에 인스턴스를 다시 시작해야 하므로 장애 조치 이벤트 중에 인스턴스 크기를 조정하면 RTO에 부정적인 영향을 미칩니다.
빠른 시작 장애 조치는 관찰자와 함께 Data Guard 브로커를 실행하는 Compute Engine 인스턴스에 구성됩니다. 관찰자는 모든 기본 및 대기 데이터베이스에 연결된 기본 Oracle 클라이언트를 실행합니다. 관찰자가 기본 데이터베이스에서 오류를 감지하면 대기 데이터베이스 중 하나로 장애 조치를 시작합니다. 골드 등급 배포를 사용하는 경우 Compute Engine에서 실행되는 대기 데이터베이스를 선호하는 장애 조치 타겟으로 구성해야 합니다.
관찰자를 기본 및 대기 데이터베이스와는 별도의 리전에 배치하는 것이 권장됩니다. 이렇게 하면 리전 장애 및 네트워크 파티셔닝 이벤트에 대한 최상의 보호를 제공할 수 있습니다. 세 번째 리전을 사용할 수 없는 경우 관찰자를 기본 리전에 설치하고 인접한 대기 데이터베이스와 다른 영역에서 실행해야 합니다.
다음 다이어그램은 배포의 예시를 보여줍니다.
다이어그램에 표시된 배포 예시는 다음으로 구성됩니다.
us-west2리전의 베어메탈 솔루션 서버에서 RAC를 실행하는 기본 데이터베이스us-west2리전의 Compute Engine 인스턴스에서 실행되는 인접한 대기 데이터베이스us-east4리전의 베어메탈 솔루션 서버에서 실행되는 원격 대기 데이터베이스us-central1리전의 Compute Engine 인스턴스에서 실행되는 Data Guard 관찰자
동기식 복제는 Compute Engine 인스턴스에서 실행되는 리전 내 대기 데이터베이스에 구성되고 비동기식 복제는 원격 리전에 구성됩니다. 각 경우 기본 데이터베이스에서 대기 데이터베이스로 재실행이 전송됩니다. 재실행은 한 대기 데이터베이스에서 다른 대기 데이터베이스로 전달되지 않습니다. 관찰자는 세 번째 리전에 구성되며 구성의 모든 데이터베이스와의 연결을 유지합니다. 애플리케이션 인스턴스는 기본 리전에서 구성되며 베어메탈 솔루션 서버의 기본 데이터베이스(또는 장애 조치 및 전환 작업 중에 Compute Engine 인스턴스의 데이터베이스)에 연결됩니다. 애플리케이션 인스턴스는 재해 발생 시 애플리케이션 트래픽을 처리하도록 Compute Engine의 us-east4 리전에 구성됩니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 재해: 손상 | 0 | 60초 미만 | |
| 재해: 리전 확장 실패 | 0 | 60초 미만 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 주요 데이터베이스 업그레이드 | 0 | 1~2시간
|
플래티넘 배포 2: 복제용 GoldenGate
플래티넘 배포 2는 복제에 Oracle GoldenGate를 사용합니다. GoldenGate는 블록 수준에서 복제하지 않기 때문입니다. 이를 통해 각 데이터베이스는 애플리케이션 세션의 읽기 및 쓰기를 독립적으로 처리할 수 있습니다. 변경사항을 양방향으로 복제하므로 활성/활성 데이터베이스 구성을 사용할 수 있습니다.
애플리케이션은 활성/활성 배포에 커밋하기 전에 철저히 유효성 검사를 거쳐야 하며 충돌 감지 및 해결을 고려해야 합니다.
Data Guard와 달리 GoldenGate는 Oracle 데이터베이스 서버에 추가 소프트웨어를 설치하고 유지보수해야 합니다. 활성/활성 배포에서는 일반적으로 멀티 사이트 데이터베이스 배포를 활용하기 위해 정교한 스키마와 애플리케이션 설계가 필요합니다. 사전 패키징된 많은 애플리케이션은 이 유형의 아키텍처를 지원하지 않습니다.
모든 복제에 GoldenGate를 사용하는 배포는 논리적 복제의 비동기적 특성으로 인해 데이터 손실이 없는 RPO를 지원할 수 없습니다. Data Guard를 사용하여 Compute Engine에서 실행되는 로컬 대기 데이터베이스를 배포하여 동기식 복제로 RPO 0을 제공할 수 있습니다.
다음 다이어그램은 배포의 예시를 보여줍니다.
| 서비스 중단 | 서비스 중단 유형 | RPO | RTO |
|---|---|---|---|
| 계획되지 않음 | 복구 가능한 노드 또는 인스턴스 오류 | 0 | 인스턴스를 다시 시작하는 데 필요한 시간 |
| 재해: 손상 | 수 초에서 수 분
각 위치에서 Data Guard를 사용하는 경우 0 |
0 | |
| 재해: 리전 확장 실패 | 수 초에서 수 분
각 위치에서 Data Guard를 사용하는 경우 0 |
0 | |
| 예정 | 데이터베이스 패치, OS/FW 업데이트 | 0 | 인스턴스를 업데이트하고 다시 시작하는 데 필요한 시간
RAC를 사용하는 경우 몇 초 |
| 주요 데이터베이스 업그레이드 | 0 | 0 |