Cloud SQL의 복제 정보

복제는 Cloud SQL 인스턴스 또는 온프레미스 데이터베이스의 복사본을 만들고 복사본에 대한 작업을 오프로드하는 기능입니다.

소개

복제를 사용하는 주된 이유는 성능 저하 없이 데이터베이스의 데이터 사용량을 늘리기 위해서입니다.

그 외의 이유는 다음과 같습니다.

  • 리전 간 데이터 마이그레이션
  • 플랫폼 간 데이터 마이그레이션
  • 온프레미스 데이터베이스에서 Cloud SQL로 데이터 마이그레이션

또한 원본 인스턴스가 손상되면 복제본을 승격할 수 있습니다.

Cloud SQL 인스턴스의 경우 복제된 인스턴스를 기본 인스턴스라고 하고 복사본을 읽기 복제본이라고 합니다. 기본 인스턴스와 읽기 복제본은 Cloud SQL에 있습니다.

온프레미스 데이터베이스의 경우 복제 시나리오를 외부 서버에서 복제라고 합니다. 이 시나리오에서는 복제된 데이터베이스를 소스 데이터베이스 서버라고 하고, Cloud SQL에 있는 복사본을 Cloud SQL 복제본이라고 합니다. Cloud SQL의 소스 데이터베이스 서버를 나타내는 인스턴스(소스 표현 인스턴스라고 함)도 있습니다.

재해 복구 시나리오에서는 기본 인스턴스로 변환하기 위해 복제본을 승격할 수 있습니다. 이렇게 하면 서비스 중단이 발생한 리전에 있는 인스턴스 대신 이를 사용할 수 있습니다. 복제본을 승격하여 손상된 인스턴스를 교체할 수도 있습니다.

Cloud SQL은 다음 유형의 복제본을 지원합니다.

Database Migration Service를 사용하여 소스 데이터베이스 서버에서 Cloud SQL로의 지속적 복제를 수행할 수도 있습니다. 참고: 참고 Cloud SQL에서는 사용자가 PostgreSQL의 논리 복제 기능을 사용해 자체 복제를 관리할 수 있습니다.

Cloud SQL에서는 두 외부 서버 간 복제를 지원하지 않습니다.

읽기 복제본

읽기 복제본을 사용하면 Cloud SQL 인스턴스에서 작업을 오프로드할 수 있습니다. 읽기 복제본은 기본 인스턴스의 정확한 복사본입니다. 기본 인스턴스의 데이터와 기타 변경사항은 거의 실시간으로 읽기 복제본에 업데이트됩니다.

읽기 복제본은 읽기 전용이며 여기에 쓸 수 없습니다. 읽기 복제본은 쿼리, 읽기 요청, 분석 트래픽을 처리하므로 기본 인스턴스의 부하가 줄어듭니다.

연결 이름과 IP 주소를 사용하여 복제본에 직접 연결합니다. 비공개 IP 주소를 사용하여 복제본에 연결하는 경우 연결이 기본 인스턴스에서 상속되기 때문에 복제본의 추가 VPC 비공개 연결을 만들 필요가 없습니다.

읽기 복제본을 만드는 방법에 대한 자세한 내용은 읽기 복제본 만들기를 참조하세요. 읽기 복제본을 관리하는 방법에 대한 자세한 내용은 읽기 복제본 관리를 참조하세요.

기본 인스턴스에서 HA를 사용할 때는 기본 인스턴스와 다른 영역에 읽기 복제본을 배치하는 것이 좋습니다. 이렇게 하면 기본 인스턴스가 포함된 영역에 중단이 발생해도 읽기 복제본이 계속 작동합니다. 자세한 내용은 고가용성 개요를 참조하세요.

적절한 머신 유형 선택

읽기 복제본의 머신 유형은 기본 머신과 다를 수 있습니다. 특히 기본 인스턴스가 작은 경우 복제본 인스턴스의 크기가 워크로드에 맞게 올바르게 조정되었는지 확인하기 위해 CPU 및 메모리 사용량과 같은 인스턴스의 측정항목을 모니터링해야 합니다. 크기가 작은 복제본 인스턴스는 잦은 메모리 부족(OOM) 이벤트와 같은 성능 저하가 발생하기 쉽습니다.

읽기 복제본에 기본 인스턴스보다 메모리가 적은 머신 유형이 있는 경우 max_connections 플래그에 미치는 영향

PostgreSQL 인스턴스에서 max_connections 플래그를 원하는 값으로 설정하지 않으면 Cloud SQL이 인스턴스의 메모리 양에 따라 자동으로 값을 설정합니다. 자세한 내용은 지원되는 플래그를 참조하세요. PostgreSQL에서 max_connections 값은 읽기 복제본에서 항상 기본 인스턴스보다 크거나 같아야 합니다. 따라서 읽기 복제본의 메모리가 기본 인스턴스보다 적고 max_connections 플래그를 설정하지 않은 경우 기본 인스턴스의 크기에 따라 더 큰 값의 max_connections를 상속할 수 있습니다. 이 경우 max_connections 설정에 의존하여 복제본 인스턴스에 대한 연결 수를 제한하면 값이 인스턴스 머신 유형에 비해 너무 높기 때문에 과부하가 발생할 수 있습니다. 이러한 문제를 방지하려면 다음 중 하나를 수행하세요.

  1. 복제본 인스턴스의 크기를 더 큰 머신 유형으로 조정합니다.
  2. 클라이언트 애플리케이션이 max_connections 값보다 작은 수의 연결로 제한되도록 구성합니다.
  3. 기본 인스턴스 및 복제본의 max_connections 플래그를 적절한 값으로 설정합니다.

읽기 복제본을 사용하는 해시 색인 작업

해시 색인 작업은 PostgreSQL 9.6에서 미리 쓰기 로깅을 사용하지 않습니다. Cloud SQL에는 PostgreSQL 10에서 사용 가능한 버전이 하나만 있습니다. 자세한 내용은 PostgreSQL 출시 페이지의 노란색 주의 상자에 설명되어 있습니다. 이는 Cloud SQL 읽기 복제본에도 적용됩니다.

해시 색인 업데이트는 PostgreSQL 9.6에서 읽기 복제본에 전파되지 않으므로 복제본에서 사용할 수 없습니다. 이 문제를 해결하려면 읽기 복제본이 없거나 주요 PostgreSQL 버전(10 이상)으로 업그레이드하면 됩니다.

리전 간 읽기 복제본

리전 간 복제를 사용하면 기본 인스턴스와 다른 리전에 읽기 복제본을 만들 수 있습니다. 리전 내 복제본 만들기와 동일한 방식으로 리전 간 읽기 복제본을 만듭니다.

리전 간 복제본:

  • 복제본을 애플리케이션의 리전에 더 가깝게 만들어 읽기 성능을 개선합니다.
  • 리전 오류로부터 보호하도록 추가 재해 복구 기능을 제공합니다.
  • 한 리전에서 다른 리전으로 데이터를 마이그레이션할 수 있습니다.

리전 간 복제본에 대한 자세한 내용은 리전 마이그레이션 또는 재해 복구용 복제본 승격을 참조하세요.

연쇄 읽기 복제본

연쇄 복제를 사용하면 동일한 리전이나 다른 리전의 다른 읽기 복제본 아래에서 읽기 복제본을 만들 수 있습니다. 다음은 연쇄 복제본을 사용하는 몇 가지 경우입니다.

  • 재해 복구: 읽기 복제본의 연쇄 계층 구조를 사용하여 기본 인스턴스와 읽기 복제본의 토폴로지를 시뮬레이션할 수 있습니다. 서비스 중단 중에 선택한 읽기 복제본이 기본 인스턴스로 승격되고 새 기본 인스턴스 아래에 있는 읽기 전용 복제본이 계속 복제되어 사용할 준비가 됩니다.
  • 성능 개선: 복제 작업을 여러 읽기 복제본으로 오프로드하여 기본 인스턴스의 부담을 줄입니다.
  • 읽기 확장: 읽기 로드를 공유할 복제본이 더 있을 수 있습니다.
  • 비용 절감: 다른 리전의 리전 간 복제와 함께 하나의 연쇄 복제본을 사용하여 네트워킹 비용을 줄일 수 있습니다.

용어

  • 연쇄 복제본: 자체 복제본을 가질 수 있는 읽기 복제본입니다.
  • 수준: 연쇄 복제본 계층 구조에서 복제본 수준을 만들 수 있습니다. 예를 들어 한 인스턴스에 4개의 복제본을 추가하면 해당 4개의 복제본은 동일한 수준에 있게 됩니다.
  • 동위 인스턴스: 동일한 기본 인스턴스에서 복제되는 여러 복제본입니다. 동위 요소는 복제본 계층 구조에서 동일한 수준에 있습니다. 복제본에는 공식적으로 8개의 동위 요소가 있을 수 있습니다.
  • 리프 복제본: 자체 복제본이 없는 읽기 복제본입니다. 다중 수준 복제 계층 구조에서 리프 복제본은 마지막 수준입니다.
  • 승격: 계층 구조의 모든 수준에서 복제본을 기본 인스턴스로 변환하는 작업입니다. 승격되면 복제본의 연쇄 복제본 계층 구조가 유지됩니다.

연쇄 복제본 구성

연쇄 복제본을 사용하면 기존 복제본에 읽기 복제본을 추가할 수 있습니다. 기본 인스턴스를 포함하여 최대 4개 수준의 복제본을 추가할 수 있습니다. 복제본이 연쇄 복제본 계층 구조의 맨 위로 승격되면 기본 인스턴스가 되고 해당 연쇄 복제본은 계속 복제됩니다.

구성을 계획하려면 읽기 복제본이 수행하려는 목표를 설정해야 합니다. 다음 두 섹션에서는 재해 복구 및 멀티 리전 복제를 위한 구성을 설명합니다.

재해 복구

연쇄 복제본이 서비스 중단 시 빠르게 복구하는 방법을 이해하려면 다음 복제 시나리오를 고려하세요.

구성

개별 리전에 연쇄 복제본이 있는 연쇄 복제본 구성 다이어그램

서비스 중단 : 중단

서비스 중단 시 프로모션 다이어그램

프로모션

복제본이 있는 새 인스턴스의 다이어그램

재해 복구 구성의 리전 B에 있는 인스턴스를 사용하려면 다음 안내를 따르세요.

  • 기본 인스턴스에 연결된 동일한 리전의 복제본(복제본 A)
  • 기본 인스턴스에 연결된 다른 리전의 복제본(연쇄 복제본)

리전 B의 연쇄 복제본에서 읽기 복제본을 만들 수 있습니다.

서비스 중단 탭에서 리전 A에 서비스 중단이 발생하면 연쇄 복제본이 기본 인스턴스로 승격됩니다. 아래에 이미 읽기 복제본이 있으므로 복구 시간 목표(RTO)가 감소합니다.

승격 탭에서 연쇄 복제본이 승격되면 해당 복제본도 승격되어 계속 복제됩니다.

멀티 리전 복제

연쇄 복제본의 또 다른 사용 사례는 비용 효율적인 방식으로 읽기 용량을 두 번째 리전에 분산하는 것입니다. 복제본 B에서 복제되는 연쇄 복제본 C와 D를 만들 수 있습니다. 클라이언트는 복제본 B, C, D에 읽기 쿼리를 분산하여 각 복제본의 로드를 줄일 수 있습니다. 리전 간 네트워크 트래픽 비용은 기본 인스턴스에서 복제본 B로 한 번만 발생합니다. B에서 C, D로 복제 시 무료 리전 내 네트워크 전송을 사용합니다.

멀티 리전 복제에 연쇄 복제본을 사용하여 최대 4개의 인스턴스로 계층 구조를 만들 수 있습니다.

기본 A → 복제본 B → 복제본 C 및 복제본 D

제한사항

  • 하위 수준에 복제본이 있는 복제본은 삭제할 수 없습니다. 복제본을 삭제하려면 리프 복제본부터 시작하여 계층 구조를 따라 위로 이동해야 합니다.
  • 순환 리전 종속 항목은 지원되지 않습니다. 연쇄 복제본의 복제본을 기본 인스턴스와 동일한 리전에 위치시키려면 연쇄 복제본도 동일한 리전에 있어야 합니다.

논리 복제

Cloud SQL을 사용하면 PostgreSQL의 논리적 복제 기능을 사용하여 자체 복제 솔루션을 구성할 수 있습니다. 논리적 복제는 다음을 허용하는 유연한 솔루션입니다.

  • 기본 인스턴스에서 복제본으로 표준 복제
  • 특정 테이블 또는 행의 선택적 복제
  • PostgreSQL 주요 버전 간의 복제
  • PostgreSQL 이외의 데이터베이스에 대한 복제
  • 모든 데이터베이스 변경사항이 소비자로 스트리밍되는 변경 데이터 캡처(CDC) 워크플로

자세한 내용은 논리 복제 설정을 참조하세요. 이 페이지에는 다음과 같은 정보가 포함되어 있습니다.

  • 기본 논리 복제
  • pglogical 확장 프로그램

복제 사용 사례

다음은 복제 유형별 사용 사례입니다.

이름 기본 복제본 장점 및 사용 사례 추가 정보
읽기 복제본 Cloud SQL 인스턴스 Cloud SQL 인스턴스
  • 추가 읽기 용량
  • 애널리틱스 대상
리전 간 읽기 복제본 Cloud SQL 인스턴스 Cloud SQL 인스턴스
  • 추가 읽기 용량
  • 애널리틱스 대상
  • 추가 재해 복구 기능
  • 읽기 성능 향상
  • 리전 간 데이터 마이그레이션
논리 복제 모든 PostgreSQL 인스턴스 모든 PostgreSQL 인스턴스 또는 외부 소비자
  • Cloud SQL 외부에서 복제
  • PostgreSQL 버전 간 복제
  • 행 및 열 필터링을 사용하여 일부 테이블의 데이터 하위 집합만 복제합니다. PostgreSQL 10의 pglogical 2.1 및 논리 복제도 참조하세요.
  • PostgreSQL 이외의 대상에 대한 복제(변경 데이터 캡처)

결제

  • 읽기 복제본에는 표준 Cloud SQL 인스턴스와 동일한 요금이 청구됩니다. 데이터 복제에는 요금이 청구되지 않습니다.
  • 리전 간 읽기 복제본의 가격은 리전에서 새 Cloud SQL 인스턴스를 만드는 경우와 동일합니다. Cloud SQL 인스턴스 가격 책정을 참조하여 적절한 리전을 선택합니다. 네트워크 이그레스 가격 책정의 설명대로 인스턴스와 관련된 일반 비용 외에도 리전 간 복제본에는 기본 인스턴스에서 복제본 인스턴스로 전송된 복제 로그에 대한 리전 간 데이터 전송 요금이 발생합니다.

Cloud SQL 읽기 복제본의 빠른 참조

주제 토론
백업 복제본에서 백업을 구성할 수 없습니다.
코어 및 메모리 읽기 복제본의 코어 개수 및 메모리 양은 기본 인스턴스와 다를 수 있습니다.
기본 인스턴스 삭제 기본 인스턴스를 삭제하려면 기본 인스턴스의 모든 읽기 복제본을 독립 실행형 인스턴스로 승격하거나 삭제해야 합니다.
복제본 삭제 복제본을 삭제해도 기본 인스턴스의 상태에는 영향을 주지 않습니다.
미리 쓰기 로깅 중지 기본 인스턴스에서 미리 쓰기 로그를 중지하려면 먼저 모든 읽기 복제본을 승격하거나 삭제해야 합니다.
장애 조치 기본 인스턴스는 복제본이 DR 복제본인 경우에만 복제본으로 장애 조치할 수 있습니다. 읽기 복제본은 중단 시 어떤 방식으로도 장애 조치를 수행할 수 없습니다.
고가용성 읽기 복제본을 사용하면 복제본에서 고가용성을 사용 설정할 수 있습니다.
부하 분산 Cloud SQL은 복제본 간의 부하 분산을 제공하지 않습니다. Cloud SQL 인스턴스에 부하 분산을 구현할 수 있습니다. 또한 연결 풀링을 사용하여 부하 분산 설정으로 복제본 간에 쿼리를 분산하여 성능을 개선할 수 있습니다.
유지보수 기간 읽기 복제본에 유지보수 기간을 구성할 수 없습니다. 그러나 읽기 복제본은 기본 인스턴스와 유지보수 기간을 공유합니다. 유지보수 중에 Cloud SQL은 기본 인스턴스를 업데이트하기 전에 모든 읽기 복제본을 먼저 업데이트합니다.
여러 읽기 복제본 Cloud SQL은 연쇄 복제본을 지원합니다. 따라서 기본 인스턴스 하나에 복제본을 최대 10개까지 만들 수 있으며 복제본은 기본을 포함하여 최대 4가지 수준으로 연결될 수 있습니다.
비공개 IP 비공개 IP 주소를 사용하여 복제본에 연결하는 경우 기본 인스턴스에서 상속되기 때문에 복제본의 추가 VPC 비공개 연결을 만들 필요가 없습니다.
기본 인스턴스 복원 복제본이 있는 동안에는 복제본의 기본 인스턴스를 복원할 수 없습니다. 백업에서 인스턴스를 복원하거나 인스턴스에 point-in-time recovery를 수행하기 전에 복제본을 모두 승격하거나 삭제해야 합니다.
설정 postgres 사용자의 비밀번호와 사용자 테이블의 변경사항을 포함한 기본 인스턴스 설정은 복제본에 반영됩니다.
복제본 중지 복제본을 stop할 수 없습니다. 복제본에 restart, delete 또는 disable replication을 할 수 있지만 기본 인스턴스처럼 중지할 수는 없습니다.
복제본 업그레이드 읽기 복제본에는 가용성에 지장을 주는 업그레이드가 언제든지 진행될 수 있습니다.
사용자 테이블 복제본은 변경할 수 없습니다. 모든 사용자 변경 작업은 기본 인스턴스에서 수행되어야 합니다.

다음 단계