이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Cloud SQL의 복제 정보

MySQL | PostgreSQL | SQL Server

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

소개

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

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

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

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

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

온프레미스 데이터베이스의 경우 복제 시나리오를 외부 서버에서 복제라고 합니다. 이 시나리오에서는 복제된 데이터베이스를 소스 데이터베이스 서버라고 하고, 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에서는 두 외부 서버 간 복제를 지원하지 않습니다. 하지만 Cloud SQL은 전역 트랜잭션 식별자(GTID) 기반 복제를 지원합니다. GTID는 서버 및 복제 설정 내에서 각 트랜잭션을 고유하게 식별합니다. 각 트랜잭션에는 고유 식별자가 있으므로 MySQL 서버는 실행된 트랜잭션을 추적할 수 있습니다. GTID는 Cloud SQL 인스턴스 복제본이 주 인스턴스를 가리킬 수 있도록 절대 좌표를 사용하며, 이때 바이너리 로그의 파일 이름이나 CHANGE MASTER 문에서 위치를 지정할 필요가 없습니다. 복제본 및 PITR(point-in-time recovery)에서는 오류가 적어집니다. 이러한 이점으로 인해 Cloud SQL에서는 GTID 기반 복제를 사용 중지할 수 없습니다.

읽기 복제본

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

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

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

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

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

적절한 머신 유형 선택

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

리전 간 읽기 복제본

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

리전 간 복제본:

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

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

연쇄 읽기 복제본

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

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

용어

연쇄 복제본: 자체 복제본을 가질 수 있는 읽기 복제본입니다.
수준: 연쇄 복제본 계층 구조에서 복제본 수준을 만들 수 있습니다. 예를 들어 한 인스턴스에 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 기본 인스턴스에서 복제되는 외부 MySQL 인스턴스입니다. 예를 들어 Compute Engine에서 실행되는 MySQL 인스턴스는 외부 인스턴스로 간주됩니다.

외부 읽기 복제본에는 다음과 같은 제한사항이 있습니다.

다른 클라우드 플랫폼에서 호스팅되는 MySQL 인스턴스로 복제하지 못할 수 있습니다. 다른 제공업체의 문서를 확인하세요. 예를 들어 replicate-ignore-db 구성 필드를 설정해야 하며, 이를 허용하지 않는 클라우드 제공업체는 지원되지 않습니다. 다른 필수 구성 필드는 외부 복제본 구성을 참조하세요.
예를 들어 네트워크나 서버의 장애로 인해 복제가 몇 시간 동안 중단되면 복제본은 기본 인스턴스보다 뒤처지게 됩니다. 복제본이 기본 인스턴스와 다시 연결되어 다시 복제를 시작하면 기본 인스턴스를 따라잡습니다. 그러나 Cloud SQL 복제 로그가 보존되는 시간(백업 7개)보다 더 오랫동안 복제가 중단될 경우에는 복제본을 삭제하고 새 복제본을 만들어야 합니다.
기본 인스턴스에서 외부 복제본으로 이동하는 데이터에는 아웃바운드 데이터 전송 요금이 청구됩니다. Cloud SQL 인스턴스 유형의 데이터 전송 가격 책정은 가격 책정 페이지를 참조하세요.
인스턴스의 외부 읽기 복제본을 만들고 Cloud SQL 인증 프록시 또는 Cloud SQL 언어 커넥터만 사용하여 비공개 서비스 액세스가 구성된 인스턴스에 연결하도록 적용하는 경우 복제본의 하위 네트워크 범위를 기본 인스턴스의 승인된 네트워크에 추가해야 합니다. 모든 범위를 Cloud SQL 인스턴스의 승인된 네트워크로 구성해야 합니다.
gcloud

외부 읽기 복제본의 IP 주소 범위에서 발생하는 트래픽을 허용하도록 인스턴스의 IP 승인을 설정하려면 gcloud sql instances patch 명령어를 사용합니다.
```
gcloud sql instances patch \
--authorized-networks=IP_ADDRESS_RANGE_1/24,IP_ADDRESS_RANGE_2/24
```
IP_ADDRESS_RANGE_1 및 IP_ADDRESS_RANGE_2를 외부 읽기 복제본의 IP 주소 범위로 바꿉니다.
REST

요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 인스턴스가 포함된 Google Cloud 프로젝트의 ID 또는 프로젝트 번호
- INSTANCE_NAME: Cloud SQL 인스턴스의 이름
- IP_ADDRESS_RANGE_1: 외부 읽기 복제본의 첫 번째 IP 주소 범위입니다.
- IP_ADDRESS_RANGE_2: 외부 읽기 복제본의 두 번째 IP 주소 범위
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
JSON 요청 본문:
{ "kind": "sql#instance", "name": INSTANCE_NAME, "project": PROJECT_ID, "settings": { "ipConfiguration": { "authorizedNetworks": [{"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_1/24"}, {"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_2/24"}]}, "kind": "sql#settings" } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
cURL(Linux, macOS, Cloud Shell)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하거나 gcloud CLI에 자동으로 로그인하는 Cloud Shell을 사용하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"
PowerShell(Windows)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.
$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
-Method PATCH `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content
다음과 비슷한 JSON 응답이 표시됩니다.
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME", "status": "PENDING", "user": "user@example.com", "insertTime": "2020-01-16T02:32:12.281Z", "operationType": "UPDATE", "name": "OPERATION_ID", "targetId": "INSTANCE_NAME", "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID", "targetProject": "PROJECT_ID" }

복제 사용 사례

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

이름	기본	복제본	장점 및 사용 사례	추가 정보
읽기 복제본	Cloud SQL 인스턴스	Cloud SQL 인스턴스	추가 읽기 용량 애널리틱스 대상	읽기 복제본 만들기 읽기 복제본 관리 복제 측정항목 복제 지연 읽기 복제본 색인
리전 간 읽기 복제본	Cloud SQL 인스턴스	Cloud SQL 인스턴스	추가 읽기 용량 애널리틱스 대상 추가 재해 복구 기능 읽기 성능 향상 리전 간 데이터 마이그레이션	읽기 복제본 만들기 읽기 복제본 관리 복제 측정항목
외부 읽기 복제본	Cloud SQL 인스턴스	Cloud SQL 외부의 MySQL 인스턴스	외부 연결 시 지연 시간 감소 애널리틱스 대상 다른 플랫폼으로의 이전 경로	외부 복제본 구성
외부 서버에서 복제	Cloud SQL 외부의 MySQL 인스턴스	MySQL용 Cloud SQL 인스턴스	Cloud SQL로의 마이그레이션 경로 Google Cloud로 데이터 복제 애널리틱스 대상	외부 서버에서 복제

읽기 복제본 생성을 위한 기본 요건

기본 Cloud SQL 인스턴스의 읽기 복제본을 만들려면 먼저 인스턴스가 다음 요구사항을 충족해야 합니다.

자동 백업이 사용 설정되어 있어야 합니다.
point-in-time recovery를 사용 설정해야 하는 바이너리 로깅이 사용 설정되어 있어야 합니다. 이 로그의 영향에 대해 자세히 알아보세요.
바이너리 로깅이 사용 설정된 후에 백업이 최소 한 개 이상 생성되어 있어야 합니다.

외부 복제본의 추가 요구사항:

복제본의 MySQL 버전이 기본 인스턴스의 MySQL 버전과 동일하거나 높아야 합니다. 자세히 알아보기
보안을 위해 기본 인스턴스에 SSL/TLS를 구성해야 합니다. 자세히 알아보기

바이너리 로깅 사용 설정의 영향

읽기 복제본을 지원하려면 point-in-time recovery를 사용 설정하여 기본 인스턴스에 바이너리 로깅을 사용 설정해야 합니다. 이렇게 하면 다음과 같은 영향이 있습니다.

성능 오버헤드
Cloud SQL에서는 sync_binlog=1과 innodb_support_xa=true라는 MySQL 플래그를 통해 행 기반 복제를 사용합니다. 따라서 쓰기 작업마다 추가 디스크 fsync가 필요하므로 성능이 저하됩니다.
스토리지 오버헤드
바이너리 로그의 스토리지에는 일반 데이터와 동일한 요금이 청구됩니다. 바이너리 로그는 가장 오래된 자동 백업의 유지 기간까지 자동으로 잘립니다. Cloud SQL은 최근 자동 백업 7개와 모든 주문형 백업을 보존합니다. 바이너리 로그 크기와 이에 따른 청구 금액은 워크로드에 따라 다릅니다. 예를 들어 쓰기 작업이 많은 워크로드는 읽기 작업이 많은 워크로드보다 더 많은 바이너리 로그 공간을 사용합니다.

SHOW BINARY LOGS MySQL 명령어를 사용하여 바이너리 로그 크기를 확인할 수 있습니다.

백업이 수행되면 로그가 데이터와 함께 백업에 저장됩니다.

읽기 복제본의 바이너리 로깅

바이너리 로깅은 읽기 복제본 인스턴스에서 지원됩니다(MySQL 5.7 및 8.0만 해당). 기본 인스턴스 이름 대신 복제본의 인스턴스 이름을 사용하여 기본 인스턴스와 동일한 API 명령어로 복제본에 바이너리 로깅을 사용 설정합니다. 용어 enable binary logging와 enable point-in-time recovery는 서로 바꿔서 사용할 수 있습니다.
복제본 인스턴스(기본 인스턴스 아님)의 바이너리 로깅 내구성은 MySQL 서버가 바이너리 로그를 디스크에 동기화하는 빈도를 관리하는 sync_binlog 플래그를 사용하여 설정할 수 있습니다.
기본 인스턴스에서 백업을 사용하지 않는 경우에도 복제본에서 바이너리 로깅을 사용 설정할 수 있습니다.
이 값이 설정된 복제본을 독립형 서버로 승격하면 설정은 독립형 서버에서 안전한 값 1로 재설정됩니다.

결제

읽기 복제본에는 표준 Cloud SQL 인스턴스와 동일한 요금이 청구됩니다. 데이터 복제에는 요금이 청구되지 않습니다.
외부 복제본의 경우 기본 인스턴스에서 외부 복제본으로 이동하는 데이터에는 데이터 전송 요금이 청구됩니다. 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를 수행하기 전에 복제본을 모두 승격하거나 삭제해야 합니다.
설정	루트 비밀번호와 사용자 테이블의 변경사항이 포함된 기본 인스턴스의 MySQL 설정은 복제본에 반영됩니다. CPU 및 메모리 변경사항은 복제본에 전파되지 않습니다.
복제본 중지	복제본을 `stop`할 수 없습니다. 복제본에 `restart`, `delete` 또는 `disable replication`을 할 수 있지만 기본 인스턴스처럼 중지할 수는 없습니다.
복제본 업그레이드	읽기 복제본에는 가용성에 지장을 주는 업그레이드가 언제든지 진행될 수 있습니다.
사용자 테이블	복제본은 변경할 수 없습니다. 모든 사용자 변경 작업은 기본 인스턴스에서 수행되어야 합니다.

다음 단계

읽기 복제본 생성 방법 알아보기
외부 복제본 구성 방법 알아보기
외부 서버에서 데이터 복제 방법 알아보기
외부 서버 구성 방법 알아보기
MySQL의 복제 알아보기
고가용성 인스턴스 구성 방법 알아보기