이 페이지에서는 Cloud SQL 인스턴스의 인플레이스 업그레이드 및 다운그레이드를 수행하는 방법을 설명합니다.
Cloud SQL 인스턴스에 인플레이스 변경하기
인플레이스 변경을 사용하여 Cloud SQL 인스턴스의 버전, 머신 유형, 스토리지 유형 또는 데이터베이스 버전을 업그레이드하거나 다운그레이드할 수 있습니다. 인플레이스 변경은 인스턴스를 재구성하는 가장 쉽고 오류가 발생할 가능성이 가장 낮은 방법입니다.
시작하기 전에
인스턴스가 MySQL 버전 8.0.31 이상에서 실행 중인지 확인합니다.
인스턴스가 이전 버전의 MySQL에서 실행 중이면 MySQL 8.0.31 이상으로 업그레이드해야 합니다. 자세한 내용은 데이터베이스 메이저 버전 인플레이스 업그레이드 및 데이터베이스 마이너 버전 업그레이드를 참조하세요.
머신 유형과 관련된 잠재적 스토리지 변경사항에 유의하기
버전마다 다른 스토리지 옵션을 사용하는 다른 머신 유형을 지원합니다. 고성능 C4 및 C4A 머신 유형은 Hyperdisk Balanced 스토리지를 이전 머신 유형에서 사용되는 영구 디스크 옵션 중 하나가 아닌 사용합니다.
사용 중인 버전 또는 머신 유형을 변경하면 스토리지 유형도 변경될 수 있으며, 이로 인해 다운타임이 발생하고 스토리지 비용이 변경될 수 있습니다. Google Cloud Hyperdisk Balanced로 이동할 때 지정할 수 있는 추가 구성 옵션이 있습니다. 자세한 내용은 스토리지 변경을 참조하세요.
PITR 트랜잭션 로그 스토리지 변경사항에 유의하기
디스크에 PITR에 사용되는 바이너리 로그를 저장하는 Cloud SQL Enterprise 버전 인스턴스를 업그레이드하는 경우 Cloud SQL Enterprise Plus 버전으로의 업그레이드 프로세스에서 이러한 로그의 스토리지 위치를 디스크에서 Cloud Storage로 이동합니다. 인스턴스의 PITR 바이너리 로그의 현재 위치를 확인하려면 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인을 참조하세요.
인플레이스 업그레이드가 바이너리 로그의 위치에 미치는 영향에 대한 자세한 설명은 PITR의 바이너리 로그 스토리지 위치 변경을 참조하세요.
인스턴스의 버전을 인플레이스로 변경하기
이 섹션에서는 Cloud SQL 인스턴스의 버전을 Cloud SQL Enterprise Plus 버전으로 또는 Cloud SQL Enterprise Plus 버전에서 인플레이스로 변경하는 방법을 보여줍니다. Cloud SQL Enterprise Plus 버전은 Cloud SQL Enterprise 버전에는 없는 몇 가지 이점과 성능 개선사항을 제공합니다. Cloud SQL 버전에 대한 자세한 내용은 Cloud SQL 버전 개요를 참조하세요.
Cloud SQL Enterprise Plus 버전으로 업그레이드하는 데 몇 분이 걸리며 다운타임은 거의 없습니다. Cloud SQL Enterprise 버전으로 다시 전환하면 다운타임이 더 길어집니다. 두 프로세스 모두 애플리케이션이 연결하는 엔드포인트를 변경할 필요가 없습니다.
이 섹션의 절차를 사용하여 Cloud SQL Enterprise 버전 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하거나 Cloud SQL Enterprise Plus 버전 인스턴스를 Cloud SQL Enterprise 버전으로 다운그레이드합니다.
콘솔
-
Cloud de Confiance 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
- 수정 을 클릭합니다.
- 인스턴스에서 Cloud SQL Enterprise 버전을 사용하는 경우 Cloud SQL 버전 선택 섹션에서 업그레이드 를 클릭하고, 인스턴스에서 Cloud SQL Enterprise Plus 버전을 사용하는 경우 Enterprise로 전환 을 클릭합니다.
- 열리는 패널을 사용하여 새 버전을 사용하여 인스턴스의 구성을 지정합니다. [인플레이스 변경 시 옵션](#change-options)을 참조하세요.
- 인스턴스 ID를 입력하여 이러한 선택사항을 확인한 후 업그레이드 또는 다운그레이드 여부에 따라 버전 업그레이드 또는 버전 전환 을 클릭합니다.
인스턴스의 작업 열에서 수정 을 선택하면 인스턴스 페이지에서 버전 변경을 시작할 수도 있습니다.
또한 인스턴스가 Cloud SQL Enterprise 버전에 있는 경우 인스턴스 페이지의 구성 섹션에 있는 버전 필드 옆에 있는 업그레이드 링크를 클릭하여 업그레이드를 시작할 수 있습니다.
gcloud
다음 [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) 코드 샘플에서는 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하는 방법을 보여줍니다.
gcloud sql instances patch INSTANCE_ID \ --edition=enterprise-plus \ --tier=MACHINE_TYPE \ --project=PROJECT_ID
다음을 바꿉니다.
- PROJECT_ID: 업그레이드할 인스턴스의 프로젝트 ID
- INSTANCE_ID: 업그레이드할 인스턴스의 이름
- MACHINE_TYPE: 업그레이드하려는 인스턴스의 머신 유형. Cloud SQL Enterprise Plus 버전의 머신 유형에 대한 자세한 내용은 머신 유형 Cloud SQL Enterprise Plus 버전 인스턴스의을 참조하세요.
REST
다음 명령어는 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하고 다시 시작 작업을 트리거합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 업그레이드할 인스턴스의 프로젝트 ID
- INSTANCE_ID: 업그레이드할 인스턴스의 인스턴스 ID
- MACHINE_TYPE: 업그레이드하려는 인스턴스의 머신 유형. Cloud SQL Enterprise Plus 버전의 머신 유형에 대한 자세한 내용은 Cloud SQL Enterprise Plus 버전 인스턴스의 머신 유형을 참조하세요.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{
"settings": {
"tier": "MACHINE_TYPE",
"edition": "ENTERPRISE_PLUS",
"dataCacheConfig": {
"dataCacheEnabled": true
},
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
REST v1beta4
다음 명령어는 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하고 다시 시작 작업을 트리거합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 업그레이드할 인스턴스의 프로젝트 ID
- INSTANCE_ID: 업그레이드할 인스턴스의 인스턴스 ID
- MACHINE_TYPE: 업그레이드하려는 인스턴스의 머신 유형. Cloud SQL Enterprise Plus 버전의 머신 유형에 대한 자세한 내용은 Cloud SQL Enterprise Plus 버전 인스턴스의 머신 유형을 참조하세요.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{
"settings": {
"tier": "MACHINE_TYPE",
"edition": "ENTERPRISE_PLUS",
"dataCacheConfig": {
"dataCacheEnabled": true
},
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
인플레이스 변경 옵션
Cloud SQL 인스턴스의 버전을 변경하려면 머신 시리즈를 변경해야 할 수 있으며, 이는 스토리지 유형에 영향을 미칩니다.
머신 변경
버전을 변경할 때는 머신 유형도 변경해야 합니다. Cloud SQL에서 지원하는 머신 시리즈에 대한 자세한 내용은 머신 시리즈 선택을 참조하세요.
Cloud SQL Enterprise 버전에서 Cloud SQL Enterprise Plus 버전으로 업그레이드할 때는 N2, C4A, 및 C4 머신 시리즈 중에서 선택할 수 있습니다.
Cloud SQL Enterprise Plus 버전에서 Cloud SQL Enterprise 버전으로 다운그레이드할 때는 범용 전용 코어와 N4 머신 시리즈 중에서 선택할 수 있습니다.
버전을 변경하지 않고 머신 유형을 변경할 수도 있습니다. 인스턴스 수정을 선택한 후 인스턴스 맞춤설정 영역의 머신 구성 에서 머신 하위 섹션으로 이동합니다. 드롭다운을 사용하여 다른 머신 유형을 선택할 수 있습니다. 또한 적절한 경우 다른 VCPU 수를 선택하고 데이터 캐시를 사용 설정하거나 사용 중지할 수 있습니다.
일반적인 자세한 내용은 Compute Engine 문서에서 N2, C4A, C4, N4 머신 시리즈를 참조하세요.
스토리지 변경
범용 또는 N2 머신 시리즈에서 N4, C4A 또는 C4 머신 시리즈로 변경하는 경우 스토리지가 솔리드 스테이트 드라이브 (SSD) 에서 Google Cloud Hyperdisk Balanced 스토리지로 마이그레이션됩니다. 이 업그레이드에는 일반적으로 최소한의 다운타임이 필요합니다.
Google Cloud Hyperdisk Balanced 스토리지는 다음을 설정하여 사용 사례에 맞게 맞춤설정할 수 있습니다.
- 스토리지 용량
- 프로비저닝된 IOPS
- 프로비저닝된 처리량
Google Cloud Hyperdisk Balanced는 머신 유형과 스토리지 용량을 포함한 인스턴스의 구성을 기반으로 기본 IOPS 및 처리량 값과 한도를 설정합니다. 스토리지 용량은 기본값을 제한하고 머신 유형은 IOPS 및 처리량의 최댓값을 설정합니다. 자세한 내용은 스토리지 옵션 선택 을 참조하세요.
PITR의 바이너리 로그 위치 변경
Cloud SQL Enterprise 버전 인스턴스에서 PITR의 트랜잭션 로그를 디스크에 저장하는 경우 Cloud SQL Enterprise Plus 버전으로 업그레이드 프로세스를 시작하면 이러한 로그의 스토리지 위치가 Cloud Storage로 전환됩니다.
위치 변경에는 다음 조건이 적용됩니다.
- 이 프로세스는 Cloud Storage로의 전환을 완료하는 데 대략
transactionLogRetentionDaysPITR 구성 설정 기간이 걸립니다. - 인스턴스에
expire_logs_days또는binlog_expire_logs_seconds플래그의 값이 설정되어 있는 경우 해당 값이 유지됩니다. - Cloud Storage로 전환하는 동안에는 인스턴스에서
expire_logs_days또는binlog_expire_logs_seconds플래그 값을 수정할 수 없습니다. - Cloud Storage로 전환하는 동안에는
transactionLogRetentionDaysPITR 구성 설정을 수정하지 않는 것이 좋습니다.transactionLogRetentionDays를 증가시키더라도 바이너리 로그는 Cloud SQL Enterprise 버전 인스턴스의 기본 7일보다 오래 디스크에 보관되지 않습니다.
- 전환이 진행 중인 동안에는 Cloud SQL에서 다음 중 하나의 최솟값 동안만 로그를 디스크에 보관합니다.
- 전환 전의
transactionLogRetentionDaysPITR 구성 설정(기본적으로 7일) - 인스턴스에 수동으로 설정된
expire_logs_days또는binlog_expire_logs_seconds플래그
- 전환 전의
- 전환 후 Cloud SQL은, 개발자가 인스턴스에
expire_logs_days또는binlog_expire_logs_seconds플래그를 설정하지 않은 한 전환 전과 동일한 양의 바이너리 로그를 디스크에 보관합니다. 이러한 플래그를 설정한 경우 Cloud SQL은transactionLogRetentionDays구성 설정 최솟값이나 플래그 값에 따라 바이너리 로그를 디스크에 보관합니다.
Cloud SQL Enterprise Plus 버전 백업 및 로그 스토리지 기본값
인스턴스에서 Cloud Storage로의 전환이 완료된 후 Cloud SQL은 복제 용도로 바이너리 로그 복사본을 디스크에 계속 보관합니다.
디스크에 바이너리 로그를 저장하는 것은 mysqlbinlog 유틸리티로 바이너리 로그를 탐색하려는 경우에 유용할 수 있습니다.
업그레이드 전 인스턴스에서 expire_logs_days 및 binlog_expire_logs_seconds 플래그를 구성한 경우 구성된 값은 그대로 유지됩니다.
전환 후에는 PITR을 수행하는 데 사용되는 바이너리 로그가 이제 Cloud Storage에 저장되므로 플래그 값이 예상 디스크에 대한 트랜잭션 로그 보관을 반영하는지 확인합니다. Cloud SQL은 다음 중 하나의 최솟값에 대한 로그를 디스크에만 보관합니다.
- 전환하기 전
transactionLogRetentionDaysPITR 구성 설정, 기본적으로 7일 - 인스턴스에 수동으로 설정된
expire_logs_days또는binlog_expire_logs_seconds플래그
디스크 공간을 절약하려면 업그레이드가 완료된 후, 1일에 해당하는 값으로 expire_logs_days 또는 binlog_expire_logs_seconds 플래그의 값을 구성하여 할당된 디스크 크기 및 디스크 스토리지 비용을 줄일 수 있게 하세요. 트랜잭션 로그 스토리지 및 PITR에 대한 자세한 내용은 PITR의 로그 스토리지를 참조하세요.
Cloud SQL Enterprise Plus 버전으로 업그레이드 후에는 업그레이드된 모든 인스턴스의 기본 트랜잭션 로그 보관 기간이 14일로 증가합니다. 이 증가와 트랜잭션 로그 보관 기간에 구성한 다른 모든 증가의 경우 PITR의 최대 보관 기간에 도달할 때까지 증가된 새 값을 사용합니다. 예를 들어 트랜잭션 로그 보관 일수의 이전 값이 7이고 새 값이 14로 증가한 경우, 업그레이드 후 처음 7일 동안의 PITR 기간은 7일만 해당합니다. 8번째 날에는 PITR의 기간이 8일이 되고, 9번째 날은 9일이 되며, 마침내 보관 기간인 14일째가 되면 14일로 늘어납니다.
또한 자동 백업의 기본 수가 8개에서 15개로 증가합니다.
주 버전 업그레이드 후에 Cloud SQL Enterprise Plus 버전으로 업그레이드하면 주 버전 업그레이드 전에 발생하는 특정 시점까지 PITR을 수행할 수 없습니다. 이 제한사항은 보관 기간이 해당 기간을 포함하는 경우에도 적용됩니다. 주 버전 업그레이드를 시작한 후에 인스턴스를 특정 시점으로 복원할 수 있습니다.