이 페이지에서는 Cloud SQL의 재해 복구를 소개합니다.
개요
Google Cloud에서 데이터베이스 재해 복구(DR)는 특히 리전이 실패하거나 사용할 수 없게 될 때 처리의 연속성을 제공합니다. Cloud SQL은 리전 서비스입니다(Cloud SQL이 HA용으로 구성된 경우). 따라서 Cloud SQL 데이터베이스를 호스팅하는 Google Cloud 리전을 사용할 수 없으면 Cloud SQL 데이터베이스도 사용할 수 없게 됩니다.
처리를 계속하려면 최대한 빨리 보조 리전에서 데이터베이스를 사용할 수 있도록 해야 합니다. DR 계획을 사용하려면 Cloud SQL에서 리전 간 읽기 복제본을 구성해야 합니다. 내보내기/가져오기 또는 백업/복원에 기반한 장애 조치도 가능하지만 이 접근 방법은 특히 대규모 데이터베이스의 경우 시간이 더 오래 걸립니다.
다음 비즈니스 시나리오는 리전 간 장애 조치 구성을 적용하는 예시입니다.
- 비즈니스 애플리케이션의 서비스수준계약이 리전 Cloud SQL 서비스수준계약(Cloud SQL 버전에 따라 가용성 99.99%)보다 큽니다. 다른 리전으로 장애 조치를 수행하면 서비스 중단을 완화할 수 있습니다.
- 비즈니스 애플리케이션의 모든 등급은 이미 멀티 리전이며 리전 중단 발생 시 계속 처리를 진행할 수 있습니다. 리전 간 장애 조치 구성을 통해 데이터베이스를 계속 사용할 수 있습니다.
- 필수 복구 시간 목표(RTO)와 복구 지점 목표(RPO)는 시간 단위가 아니라 분 단위입니다. 다른 리전으로 장애 조치를 수행하는 것이 데이터베이스를 다시 만드는 것보다 더 빠릅니다.
일반적으로 DR 프로세스에는 두 가지가 있습니다.
- 데이터베이스가 보조 리전으로 장애 조치됩니다. 데이터베이스가 준비되고 애플리케이션에서 사용될 경우 이 데이터베이스는 새 기본 데이터베이스가 되고 기본 데이터베이스로 유지됩니다.
- 데이터베이스가 보조 리전으로 장애 조치되지만 기본 리전이 장애에서 복구된 후 기본 리전으로 대체됩니다.
이 Google Cloud SQL 데이터베이스 재해 복구 개요에서는 실패한 데이터베이스가 복구되고 기본 리전으로 되돌아가는 두 번째 변형을 설명합니다. 이 DR 프로세스 변형은 특히 네트워크 지연 시간으로 인해 또는 기본 리전에서만 일부 리소스를 사용할 수 있어 기본 리전에서 실행해야 하는 데이터베이스와 관련이 있습니다. 이 변형을 사용하면 데이터베이스는 기본 리전의 서비스 중단 기간 동안에만 보조 리전에서 실행됩니다.
이 DR 문서와 관련된 가이드는 다음 2개입니다.재해 복구 아키텍처
다음 다이어그램은 HA Cloud SQL 인스턴스의 데이터베이스 DR을 지원하는 최소한의 아키텍처를 보여줍니다.
이 아키텍처는 다음과 같이 작동합니다.
- Cloud SQL의 두 인스턴스(기본 인스턴스 및 대기 인스턴스)는 단일 리전(기본 리전) 내의 두 영역에 있습니다. 인스턴스는 리전 영구 디스크를 사용하여 동기화됩니다.
- Cloud SQL의 인스턴스 중 하나(리전 간 읽기 복제본)는 두 번째 리전(보조 리전)에 있습니다. DR의 경우 비동기 복제를 사용하여 리전 간 읽기 복제본이 읽기 복제본 설정을 사용하는 기본 인스턴스와 동기화되도록 설정됩니다.
기본 인스턴스와 대기 인스턴스는 동일한 리전 디스크를 공유하므로 인스턴스의 상태가 동일합니다.
이 설정은 비동기 복제를 사용하기 때문에 리전 간 읽기 복제본이 기본 인스턴스보다 뒤쳐질 수 있습니다. 장애 조치가 발생하면 리전 간 읽기 복제본이 RPO 0을 지원할 수 있습니다.
재해 복구(DR) 프로세스
재해 복구(DR) 프로세스는 기본 리전을 사용할 수 없게 되면 시작됩니다. 보조 리전에서 처리를 재개하려면 리전 간 읽기 복제본을 승격하여 기본 인스턴스의 장애 조치를 트리거합니다. DR 프로세스에는 리전 장애를 완화하고 보조 리전에서 실행되는 기본 인스턴스를 설정하기 위해 수동 또는 자동으로 수행해야 하는 작업 단계가 기술됩니다.
다음 다이어그램은 DR 프로세스를 보여줍니다.
이 DR 프로세스는 다음과 같은 단계로 구성됩니다.
- 기본 인스턴스를 실행하는 기본 리전(R1)은 사용할 수 없게 됩니다.
- 운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
- 장애 조치가 필요한 경우 보조 리전(R2)의 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 됩니다.
- 클라이언트 연결은 새로운 기본 인스턴스에서 처리를 재개하고 R2의 기본 인스턴스에 액세스할 수 있도록 재구성됩니다.
이 초기 프로세스는 작동하는 기본 데이터베이스를 다시 설정합니다. 하지만 새 기본 인스턴스 자체에 대기 인스턴스와 리전 간 읽기 복제본이 있는 완전한 DR 아키텍처는 설정하지 않습니다.
DR 프로세스를 완료하면 단일 인스턴스(새 기본 인스턴스)가 HA에 대해 사용 설정되고 리전 간 읽기 복제본을 포함하게 됩니다. 또한 DR 프로세스를 완료하면 원래 기본 리전의 원래 배포에 대한 대체를 제공합니다.
보조 리전으로 장애 조치
전체 DR 프로세스는 장애 조치 후 전체 DR 아키텍처를 설정하기 위한 단계를 추가하여 기본 DR 프로세스를 확장합니다. 다음 다이어그램은 장애 조치 후 전체 데이터베이스 DR 아키텍처를 보여줍니다.
전체 데이터베이스 DR 프로세스는 다음 단계로 구성됩니다.
- 기본 데이터베이스를 실행하는 기본 리전(R1)은 사용할 수 없게 됩니다.
- 운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
- 장애 조치가 필요한 경우 보조 리전(R2)의 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 됩니다.
- 클라이언트 연결은 새로운 기본 인스턴스(R2)에서 액세스하고 처리하도록 재구성됩니다.
- R2에서 새 대기 인스턴스가 생성되고 시작되어 기본 인스턴스에 추가됩니다. 대기 인스턴스는 기본 인스턴스와 다른 영역에 배치됩니다. 이제 기본 인스턴스를 위한 대기 인스턴스가 생성되었기 때문에 기본 인스턴스의 가용성이 높아집니다.
- 세 번째 리전(R3)에서는 새 리전 간 읽기 복제본이 생성되고 기본 인스턴스에 연결됩니다. 이 시점에서 전체 재해 복구 아키텍처가 다시 생성되고 작동됩니다.
6단계가 수행되기 전에 원래 기본 리전(R1)을 사용할 수 있게 되는 즉시, 리전 R3가 아닌 리전 R1에 리전 간 읽기 복제본을 배치할 수 있습니다. 이 경우에는 원래 기본 리전(R1)으로 대체하는 것이 쉽고 단계가 간단합니다.
분할 브레인 상태 방지
기본 리전(R1)에 장애가 발생하더라도 원래 기본 인스턴스와 대기 인스턴스가 자동으로 종료되거나, 삭제되거나, 혹은 R1이 다시 사용 가능해지면 액세스 불가 상태가 되는 것은 아닙니다. R1을 사용할 수 있게 되면 클라이언트는 원래 기본 인스턴스에서 우연히라도 데이터를 읽고 쓸 수 있습니다. 이 경우 분할 브레인 상황이 발생하여 일부 클라이언트가 이전 기본 데이터베이스의 비활성 데이터에 액세스하고 다른 클라이언트는 새 기본 데이터베이스의 최신 데이터에 액세스하여 비즈니스에 문제가 발생할 수 있습니다.
분할 브레인 상황을 방지하려면 R1을 사용할 수 있게 된 후에 클라이언트가 원래 기본 인스턴스에 액세스할 수 없도록 해야 합니다. 이상적으로는 클라이언트가 새 기본 인스턴스를 사용하기 전에 원래 기본 인스턴스에 액세스할 수 없게 만들고, 액세스할 수 없게 되는 즉시 원래 기본 인스턴스를 삭제하는 것이 좋습니다.
장애 조치 후 초기 백업 설정
장애 조치에서 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 새 기본 인스턴스의 트랜잭션이 원래 기본 트랜잭션의 인스턴스와 완전히 동기화되지 않을 수 있습니다. 따라서 새 인스턴스에서 이러한 트랜잭션을 사용할 수 없습니다.
장애 조치 시작 시와 클라이언트가 데이터베이스에 액세스하기 전에 새 기본 인스턴스를 즉시 백업하는 것이 좋습니다. 이 백업은 장애 조치 시점에 알려진 일관적인 상태를 나타냅니다. 이러한 백업은 규제 목적으로 또는 클라이언트가 새 기본 인스턴스에 액세스할 때 문제가 발생하는 경우 알려진 상태로 복구하는 데 중요합니다.
원래 기본 리전으로 대체
앞에서 설명한 것처럼 이 문서에서는 원래 리전(R1)으로 대체하기 위한 단계를 제공합니다. 대체 프로세스에 두 가지 버전이 있습니다.
- 3차 리전(R3)에서 새 리전 간 읽기 복제본을 만든 경우, 기본 리전(R1)에서 다른(보조) 리전 간 읽기 복제본을 만들어야 합니다.
- 기본 리전(R1)에서 새로운 리전 간 읽기 복제본을 만든 경우 R1에 또 다른 리전 간 읽기 복제본을 만들 필요가 없습니다.
R1의 리전 간 읽기 복제본이 존재하는 경우 Cloud SQL 인스턴스가 R1로 대체될 수 있습니다. 대체 작업은 수동으로 트리거되고 서비스 중단을 기반으로 하지 않으므로 이 유지보수 활동에 적합한 날짜와 시간을 선택할 수 있습니다.
따라서 기본, 대기, 리전 간 읽기 복제본이 있는 완전한 DR을 실행하려면 두 개의 장애 조치가 필요합니다. 첫 번째 장애 조치는 서비스 중단(실제 장애 조치)에 의해 트리거되고 두 번째 장애 조치는 시작 배포(대체)를 재설정합니다.
원래 기본 리전(R1)으로의 대체는 다음 단계로 구성됩니다.
- 원래 기본 리전(R1)에서 새로 생성된 리전 간 복제본을 승격합니다.
- 승격된 인스턴스가 원래 HA 복제본으로 생성되지 않았으면 영역 장애로부터 보호하기 위해 인스턴스에 HA를 사용 설정합니다.
- 새 기본 인스턴스에 연결하도록 애플리케이션을 다시 구성합니다.
- DR 리전(R2)에서 새 기본 인스턴스의 리전 간 복제본을 만듭니다.
- (선택사항) 여러 개의 독립적인 기본 인스턴스를 실행하지 않도록 하려면 DR 리전(R2)에서 기본 인스턴스를 삭제합니다.
고급 재해 복구(DR)
Cloud SQL Enterprise Plus 버전을 사용하는 경우 고급 DR을 활용할 수 있습니다. 고급 DR은 리전 간 장애 조치 후 복구 및 대체를 간소화합니다. 재해 복구 프로세스에 설명된 대로 DR을 수행할 때 이전 기본 인스턴스의 장애가 발생한 리전과 새 기본 인스턴스의 작동 리전 간의 연결을 삭제합니다. DR을 사용할 때 원래 배포 리전으로 연결을 복원하고 이전 기본 인스턴스를 다시 얻으려면 일련의 수동 대체 단계를 수행해야 합니다.
고급 DR을 사용하면 리전 장애가 발생할 때 복제본 장애 조치를 호출할 수 있습니다. 복제본 장애 조치를 사용하면 지정된 재해 복구(DR) 복제본을 승격한다는 점을 제외하면 일반 DR 수행과 유사한 리전 간 읽기 복제본을 승격합니다. DR 복제본의 승격이 즉시 수행됩니다. 이전 기본 인스턴스를 삭제하는 대신 인스턴스는 Cloud SQL의 비동기 복제 토폴로지의 일부로 유지됩니다. DR 복제본이 새 기본 인스턴스로 승격되면 이전 기본 인스턴스(인스턴스 A)가 결국 DR 복제본(인스턴스 B)의 복제본이 됩니다.
이전 기본 인스턴스(A)가 복제본으로 전환된 다음 고급 DR의 마지막 단계를 수행할 수 있습니다. Cloud SQL 배포를 원래 상태로 되돌리고 이전 기본 인스턴스(A)를 데이터 손실 없이 기본 인스턴스로의 이전 역할로 복원할 수 있습니다. 이전 기본 인스턴스(A)에 대해 데이터 손실 없이 복원을 수행하려면 전환 작업을 사용하면 됩니다. 전환을 수행하면 지정된 DR 복제본(A)이 기본 인스턴스(B)를 따라잡을 때까지 기본 인스턴스(B)가 읽기 전용 모드로 유지되므로 데이터가 손실되지 않습니다. DR 복제본(A)이 모든 복제 업데이트를 수신하면 DR 복제본(A)이 기본 인스턴스의 역할을 하며 이전 기본 인스턴스(B)는 현재 기본 인스턴스(A)의 DR 복제본으로 자동으로 재구성됩니다. 인스턴스가 원래 역할로 돌아가므로 DR 및 복제본 장애 조치 전 토폴로지가 원래 상태로 돌아갑니다.
고급 DR 중에 복제본 장애 조치 및 전환 작업과 관련된 모든 인스턴스는 해당 IP 주소를 유지합니다.
또한 고급 DR의 전환 작업을 사용하여 정기 DR 드릴을 수행하여 재해가 발생하기 전에 리전 간 장애 조치를 위해 Cloud SQL 토폴로지를 테스트하고 준비할 수 있습니다. 실제 재해가 발생하면 이미 테스트한 리전 간 복제본 장애 조치를 수행할 수 있습니다.
지정된 재해 복구(DR) 복제본
고급 DR의 필수 구성요소인 DR 복제본에는 다음 특성이 포함됩니다.
- DR 복제본은 직접 연결된 리전 간 읽기 복제본입니다.
- DR 복제본 지정을 여러 번 변경할 수 있습니다.
- 전환 또는 복제본 장애 조치 작업을 제외하고 언제든지 DR 복제본 지정을 변경할 수 있습니다.
또한 고급 DR을 사용한 후 RTO를 줄이려면 다음을 수행하는 것이 좋습니다.
- DR 복제본을 기본 인스턴스와 동일한 크기로 구성하기
- 기본 인스턴스에 HA가 사용 설정된 경우 DR 복제본에도 HA를 사용 설정하기
복제본 장애 조치
복제본 장애 조치는 다음 단계로 구성됩니다.
- 복제본 장애 조치를 수행하기 전에 DR 복제본이 기본 인스턴스에 할당되어 있으며, 전환을 수행하여 프로세스를 테스트했을 수 있습니다.
- 기본 데이터베이스를 실행하는 기본 리전은 사용할 수 없게 됩니다.
- 운영팀이 재해 복구가 필요하다고 결정합니다.
- 지정된 DR 복제본으로 복제본 장애 조치를 수행합니다.
- 리전 간 지정된 DR 복제본이 즉시 기본 인스턴스가 되고 수신되는 읽기 및 쓰기를 수락하기 시작합니다.
- 현재는 새 기본 인스턴스를 가리키도록 애플리케이션을 구성해야 합니다.
- 이전 기본 인스턴스를 다시 사용할 수 있게 되면 이전 기본 인스턴스는 새 기본 인스턴스의 읽기 복제본이 됩니다. 이전 기본 인스턴스는 IP 주소를 유지합니다.
복제본 장애 조치를 수행한 후에는 전환 작업을 수행하고 동일한 DR 복제본과 기본 인스턴스 쌍을 반대로 하여 원래 리전에서 기본 인스턴스를 복원할 수 있습니다.
전환
전환은 다음 단계로 구성됩니다.
- 전환 작업을 시작하기 전에 기본 인스턴스에 DR 복제본을 할당해야 합니다.
- 기본 인스턴스가 정상인지 확인합니다. 기본 인스턴스와 DR 복제본이 모두 온라인 상태인 경우에만 전환을 수행할 수 있습니다.
- 사용자가 전환을 시작합니다. 전환을 시작하면 기본 인스턴스가 쓰기 허용을 중지하고 읽기 전용이 됩니다.
- 바이너리 로그가 Cloud Storage에 복사될 때까지 기다립니다.
- 지정된 DR 복제본은 기본 인스턴스를 따라잡습니다.
- 복제 지연이 0으로 감소하면 DR 복제본이 새로운 기본 인스턴스로 승격됩니다. 새 기본 인스턴스가 애플리케이션 읽기 및 쓰기를 포함한 들어오는 연결을 수락하기 시작합니다.
- 이전 기본 인스턴스는 읽기 복제본으로 재구성됩니다.
- 현재는 새 기본 인스턴스를 가리키도록 애플리케이션을 구성해야 합니다.
- PITR은 새 기본 인스턴스에 대해 자동으로 사용 설정됩니다. PITR은 첫 번째 자동 백업 후에만 가능합니다.
다음 단계
- 고급 재해 복구(DR) 사용
- MySQL용 Cloud SQL 재해 복구 튜토리얼 사용해 보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 가이드, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기