데이터베이스 주 버전 인플레이스 업그레이드

이 페이지에서는 데이터를 마이그레이션하는 대신 Cloud SQL 인스턴스를 인플레이스 업그레이드하여 데이터베이스 주 버전을 업그레이드하는 방법을 설명합니다.

소개

데이터베이스 소프트웨어 제공업체는 새로운 기능, 성능 개선, 보안 개선사항이 포함된 새로운 주 버전을 주기적으로 출시합니다. Cloud SQL은 이러한 주 버전이 출시된 후 새 버전을 채택합니다. Cloud SQL에서 새로운 주 버전에 대한 지원이 제공된 후 인스턴스를 업그레이드하여 데이터베이스를 업데이트된 상태로 유지할 수 있습니다.

인스턴스의 데이터베이스 버전을 인플레이스로 또는 데이터 마이그레이션을 통해 업그레이드할 수 있습니다. 인플레이스 업그레이드는 인스턴스의 주 버전을 업그레이드하기 위한 더 간단한 방법입니다. 데이터를 마이그레이션하거나 애플리케이션 연결 문자열을 변경할 필요가 없습니다. 인플레이스 업그레이드의 경우 업그레이드 후 현재 인스턴스의 이름, IP 주소, 기타 설정을 유지할 수 있습니다. 인플레이스 업그레이드는 데이터 파일을 이동할 필요가 없고 더 빠르게 완료할 수 있습니다. 일부 경우에는 데이터 마이그레이션보다 다운타임이 짧습니다.

MySQL용 Cloud SQL 인플레이스 업그레이드 작업에는 mysql_upgrade 유틸리티가 사용됩니다.

주 버전 업그레이드 계획

대상 주 버전을 선택합니다.

Cloud SQL에서 지원되는 버전 목록을 참조하세요.
각 데이터베이스 주 버전에 제공된 기능을 고려해서 비호환성 문제를 해결합니다.
- MySQL 8.0
- MySQL 5.7
새로운 주 버전에는 애플리케이션 코드, 스키마, 데이터베이스 설정을 수정해야 할 수 있는 호환되지 않는 변경사항이 포함됩니다. 데이터베이스 인스턴스를 업그레이드하려면 먼저 대상 주 버전의 출시 노트를 검토하여 해결이 필요한 비호환성 문제를 확인하세요.

최신 버전으로 업그레이드하면 일부 시스템 변수의 기본값이 변경될 수 있습니다. 예를 들어 MySQL 5.6 및 MySQL 5.7에서 character_set_server의 기본값은 utf8입니다. MySQL 8.0으로 업그레이드하면 character_set_server의 기본값이 utf8mb4로 변경됩니다. utf8로 되돌리려면 데이터베이스 플래그 값을 이전 값으로 수동으로 변경해야 합니다. 자세한 내용은 데이터베이스 플래그 구성을 참조하세요. 대부분의 기본값 변경은 MySQL 커뮤니티에 의해 수행됩니다(서버 기본값 업그레이드 참조).

참고: 하나의 주 버전에서 그 다음 주 버전으로만 업그레이드할 수 있습니다. MySQL은 주 버전 건너뛰기를 지원하지 않습니다. MySQL 5.6에서 MySQL 8.0으로 바로 업그레이드할 수 없습니다.
MySQL 5.7에서 8.0으로 업그레이드되었는지 미리 확인합니다.

MySQL 5.7에서 8.0으로 업그레이드를 실행하기 전에 사전 검사를 수행합니다. MySQL 셸에서 업그레이드 검사기 유틸리티를 사용할 수 있습니다. 사전 검사 중에 문제가 발견되면 업그레이드를 진행하기 전에 수정합니다. Cloud SQL은 주 버전 업그레이드 중 사전 검사를 지원하지 않습니다. 사전 검사에 실패한 인스턴스를 업그레이드하려고 시도해도 실패할 수 있습니다.
디스크 공간 및 인스턴스 머신 유형을 확인합니다.

주 버전 업그레이드에는 업그레이드된 테이블을 저장하기 위한 디스크 공간과 같은 추가 리소스가 필요합니다. 디스크 공간이 충분하지 않으면 업그레이드가 실패하고 롤백됩니다. MySQL 5.7에서 8.0으로 업그레이드하려면 이전 메타데이터를 새 데이터 사전으로 변환하기 위해 추가 메모리가 필요합니다. 주 버전 업그레이드를 실행하기 전 각 테이블에 대해 메모리가 100K를 초과하는지 확인합니다. 머신 유형을 변경하여 메모리를 일시적으로 늘릴 수 있습니다.
MySQL 8.0에서 사용자 부여 변경사항 확인

MySQL용 Cloud SQL 버전 8.0은 partial_revokes라는 플래그를 사용하며, 이 플래그는 기본적으로 ON으로 설정됩니다. MySQL 5.7과 달리 이 플래그는 데이터베이스 GRANT 명령어에 와일드 카드 문자를 사용하는 기능을 삭제합니다. 데이터베이스 사용자가 올바른 데이터베이스 스키마에 액세스할 수 있도록 MySQL 8.0으로 업그레이드하기 전에 데이터베이스 사용자 권한을 수정합니다. 와일드 카드 문자를 사용하는 대신 필요한 데이터베이스 스키마의 전체 이름을 사용하도록 사용자 권한을 업데이트합니다.

이 플래그가 MySQL 8.0에서 작동하는 방식에 대한 자세한 내용은 MySQL 8.0의 partial_revokes를 참조하세요.
테스트 실행을 통해 업그레이드를 테스트합니다.

프로덕션 데이터베이스를 업그레이드하기 전 테스트 환경에서 엔드 투 엔드 업그레이드 프로세스의 시험 이전을 수행합니다. 인스턴스를 클론하여 업그레이드 프로세스를 테스트할 동일한 데이터 사본을 만들 수 있습니다.

업그레이드가 성공적으로 완료되는지 검증하는 것 외에도 업그레이드된 데이터베이스에서 애플리케이션이 예상한 대로 작동하는지 확인하는 테스트를 실행합니다.

참고: 메이저 버전 업그레이드를 실행하기 전에 디스크 공간이 충분한지 확인하세요. 자동 스토리지 증가를 사용 설정하지 않았으면 업그레이드된 테스트 실행 인스턴스에서 사용되는 디스크 스토리지를 기록합니다. 이렇게 하면 업그레이드하기 전 프로덕션 인스턴스의 스토리지 용량을 늘려야 하는지 여부를 확인할 수 있습니다.
업그레이드 시간을 결정합니다.

업그레이드하려면 일정 기간 동안 인스턴스가 사용 중지되어야 합니다. 데이터베이스 활동이 적은 기간에 업그레이드를 계획합니다.

주 버전 업그레이드 준비

업그레이드하기 전 다음 단계를 완료합니다.

MySQL 5.7에서 8.0으로 업그레이드하는 경우에만: 사전 확인 프로세스 중에 발견된 호환되지 않는 문제를 확인하고 수정합니다. 일반적으로 발견되는 문제는 다음과 같습니다.
1. 저장 프로시저, 트리거 등에 RANKS, GROUPS, FUNCTION과 같은 새로 예약된 키워드가 추가되었습니다. 자세한 내용은 키워드 및 예약어를 참조하세요.
2. 테이블 정의에 잘못된 UTF 문자가 있습니다.
3. 커밋해야 하는 커밋되지 않은 XA 전환(XA COMMIT 문 사용) 또는 롤백(XA ROLLBACK 문 사용)이 있습니다.
4. 이름의 외래 키 제약조건이 64자를 초과합니다.
5. 열의 혼합 색인에 공간 데이터 유형이 있습니다. 자세한 내용은 공간 데이터 유형을 참조하세요.
자세한 내용은 업그레이드를 위한 설치 준비 및 MySQL 8.0으로 업그레이드를 참조하세요.
디스크 공간 및 인스턴스 머신 유형 확인

주 버전을 업그레이드하려면 업그레이드된 테이블과 새 데이터 사전을 저장하기 위한 추가 디스크 공간과 메모리가 필요합니다. 필요한 디스크 공간이 없으면 업그레이드가 실패하고 원래 버전으로 롤백됩니다. Cloud SQL에서는 각 테이블에 대해 최소 100k의 메모리가 있는 것이 좋습니다.
참고: 주 버전 업그레이드를 실행하기 전에 머신 유형을 변경하여 메모리를 일시적으로 늘릴 수 있습니다. 자세한 내용은 머신 유형 변경을 참조하세요.
읽기 복제본을 업그레이드합니다.

읽기 복제본을 사용하는 경우 기본 인스턴스를 업그레이드하기 전에 먼저 모든 읽기 복제본을 업그레이드해야 합니다. 복제본이 업그레이드되었지만 기본 인스턴스가 업그레이드되지 않은 경우 기본 인스턴스가 복제본에서 사용하는 최신 버전의 MySQL에서 더 이상 지원되지 않는 문이나 함수를 사용하면 복제가 중단될 수 있습니다. 이러한 문제를 방지하려면 Cloud SQL에서 다음을 수행하는 것이 좋습니다.
1. 복제본을 업그레이드하는 즉시 기본 인스턴스를 업그레이드합니다.
2. 업그레이드가 성공적으로 완료될 때까지 기본 인스턴스에서 새 버전과 호환되지 않는 쿼리를 실행하지 않습니다.
3. (선택사항) 업그레이드가 성공적으로 완료될 때까지 기본 인스턴스에 대한 모든 WRITE 문을 일시중지합니다.
4. (선택사항) 기본 인스턴스를 업그레이드하기 전에 모든 복제본을 삭제하고 업그레이드가 완료된 후 복제본을 다시 만듭니다.
복제가 중단되면 복제본이 기본 인스턴스의 버전으로 롤백됩니다. 복제본을 다시 업그레이드할 수 있지만 문제가 지속되는 경우 [FAQ](#faqs)를 참조하세요.

데이터베이스 주 버전 인플레이스 업그레이드

업그레이드 작업을 시작하면 Cloud SQL이 먼저 인스턴스 구성이 업그레이드와 호환되는지 확인합니다. 구성이 확인된 후에는 Cloud SQL이 인스턴스를 사용 중지하고, 업그레이드 전 백업을 만들고, 업그레이드를 수행하고, 인스턴스를 사용하도록 설정하고, 업그레이드 후 백업을 만듭니다.

MySQL 8.0으로 업그레이드하면 Cloud SQL이 기본 부 버전으로 인스턴스를 자동으로 프로비저닝합니다.

콘솔

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
수정을 클릭합니다.
인스턴스 정보 섹션에서 업그레이드 버튼을 클릭하고 업그레이드 페이지로 이동함을 확인합니다.
데이터베이스 버전 선택 페이지에서 업그레이드할 데이터베이스 버전 목록을 클릭하고 사용 가능한 데이터베이스 주 버전 중 하나를 선택합니다.
계속을 클릭합니다.
인스턴스 ID 상자에 인스턴스 이름을 입력한 후 업그레이드 시작 버튼을 클릭합니다.

작업이 완료되는 데 몇 분 정도 걸립니다.

인스턴스 개요 페이지의 인스턴스 이름 아래에 업그레이드된 데이터베이스 주 버전이 표시되는지 확인합니다.

gcloud

업그레이드를 시작합니다.

gcloud sql instances patch 명령어를 --database-version 플래그와 함께 사용합니다.

명령어를 실행하기 전 다음 변수를 바꿉니다.
- INSTANCE_NAME: 인스턴스 이름.
- DATABASE_VERSION: 현재 버전보다 커야 하는 데이터베이스 주 버전의 열거형입니다. 사용 가능한 데이터베이스 버전 열거형을 참조하세요.
```
gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION
```
주 버전 업그레이드를 완료하려면 몇 분 정도 걸립니다. 작업이 예상보다 오래 걸릴 경우 메시지가 표시될 수 있습니다. 이 메시지를 그냥 무시하거나 gcloud sql operations wait 명령어를 실행해서 메시지를 닫아도 됩니다.
업그레이드 작업 이름을 가져옵니다.

gcloud sql operations list 명령어를 --instance 플래그와 함께 사용합니다.

명령어를 실행하기 전 INSTANCE_NAME 변수를 인스턴스 이름으로 바꿉니다.
```
gcloud sql operations list --instance=INSTANCE_NAME
```
업그레이드 상태를 모니터링합니다.

gcloud sql operations describe 명령어를 사용합니다.

명령어를 실행하기 전 OPERATION 변수를 이전 단계에서 가져온 업그레이드 작업 이름으로 바꿉니다.
```
gcloud sql operations describe OPERATION
```

REST v1

인플레이스 업그레이드를 시작합니다.

instances:patch 메서드와 함께 PATCH 요청을 사용합니다.

요청 데이터를 사용하기 전에 다음 변수를 바꿉니다.
- project_id: 프로젝트의 ID입니다.
- instance_name: 인스턴스 이름.
HTTP 메서드 및 URL:
```
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance_name
```
JSON 요청 본문:
```
{
  "databaseVersion": enum DATABASE_VERSION
}
```
DATABASE_VERSION을 데이터베이스 주 버전의 열거형으로 바꿉니다. 현재 버전보다 커야 합니다. 사용 가능한 데이터베이스 버전 열거형을 참조하세요.

curl 또는 PowerShell을 사용하여 요청을 전송합니다. 인스턴스 수정을 참조하세요.
업그레이드 작업 이름을 가져옵니다.

project_id를 프로젝트 ID로 바꿔서 operations.list 메서드와 함께 GET 요청을 사용합니다.

HTTP 메서드 및 URL:
```
GET https://sqladmin.googleapis.com/v1/projects/project-id/operations
```
업그레이드 상태를 모니터링합니다.

다음 변수를 바꾸고 operations.get 메서드와 함께 GET 요청을 사용합니다.
- project_id: 프로젝트의 ID입니다.
- operation_name: 이전 단계에서 가져온 업그레이드 작업 이름입니다.
HTTP 메서드 및 URL:
```
GET https://sqladmin.googleapis.com/v1/projects/project-id/operation/operation_name
```

Terraform

데이터베이스 버전을 업데이트하려면 Terraform 리소스 및 Google Cloud용 Terraform 제공업체 버전 4.34.0 이상을 사용합니다.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

변경사항 적용

Google Cloud 프로젝트에 Terraform 구성을 적용하려면 다음 섹션의 단계를 완료하세요.

Cloud Shell 준비

Cloud Shell을 실행합니다.
Terraform 구성을 적용할 기본 Google Cloud 프로젝트를 설정합니다.

이 명령어는 프로젝트당 한 번만 실행하면 되며 어떤 디렉터리에서도 실행할 수 있습니다.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
Terraform 구성 파일에서 명시적 값을 설정하면 환경 변수가 재정의됩니다.

디렉터리 준비

각 Terraform 구성 파일에는 자체 디렉터리(루트 모듈이라고도 함)가 있어야 합니다.

Cloud Shell에서 디렉터리를 만들고 해당 디렉터리 내에 새 파일을 만드세요. 파일 이름에는 .tf 확장자가 있어야 합니다(예: main.tf). 이 튜토리얼에서는 파일을 main.tf라고 합니다.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
튜토리얼을 따라 하는 경우 각 섹션이나 단계에서 샘플 코드를 복사할 수 있습니다.

샘플 코드를 새로 만든 main.tf에 복사합니다.

필요한 경우 GitHub에서 코드를 복사합니다. 이는 Terraform 스니펫이 엔드 투 엔드 솔루션의 일부인 경우에 권장됩니다.
환경에 적용할 샘플 매개변수를 검토하고 수정합니다.
변경사항을 저장합니다.
Terraform을 초기화합니다. 이 작업은 디렉터리당 한 번만 수행하면 됩니다.
```
terraform init
```
원하는 경우 최신 Google 공급업체 버전을 사용하려면 -upgrade 옵션을 포함합니다.
```
terraform init -upgrade
```

변경사항 적용

구성을 검토하고 Terraform에서 만들거나 업데이트할 리소스가 예상과 일치하는지 확인합니다.
```
terraform plan
```
필요에 따라 구성을 수정합니다.
다음 명령어를 실행하고 프롬프트에 yes를 입력하여 Terraform 구성을 적용합니다.
```
terraform apply
```
Terraform에 '적용 완료' 메시지가 표시될 때까지 기다립니다.
결과를 보려면 Google Cloud 프로젝트를 엽니다. Google Cloud 콘솔에서 UI의 리소스로 이동하여 Terraform이 리소스를 만들었거나 업데이트했는지 확인합니다.

변경사항 삭제

변경사항을 삭제하려면 다음 단계를 따르세요.

Terraform 구성 파일에서 삭제 보호를 사용 중지하려면 deletion_protection 인수를 false로 설정합니다.
```
deletion_protection =  "false"
```
다음 명령어를 실행하고 프롬프트에 yes를 입력하여 업데이트된 Terraform 구성을 적용합니다.
```
terraform apply
```

다음 명령어를 실행하고 프롬프트에 yes를 입력하여 이전에 Terraform 구성에 적용된 리소스를 삭제합니다.
```
terraform destroy
```

인플레이스 업그레이드 요청을 실행하면 Cloud SQL이 먼저 업그레이드 전 검사를 수행합니다. Cloud SQL에서 인스턴스 업그레이드가 준비되지 않은 것으로 확인되면 업그레이드 요청이 실패하고 문제 해결 방법을 추천하는 메시지가 표시됩니다. 또한 주 버전 업그레이드 문제 해결을 참조하세요.

자동 업그레이드 백업

주 버전 업그레이드를 수행할 때 Cloud SQL은 업그레이드 백업이라고 부르는 2개의 주문형 백업을 자동으로 만듭니다.

첫 번째 업그레이드 백업은 업그레이드 시작 직전에 수행되는 업그레이드 전 백업입니다. 이 백업을 사용하면 데이터베이스 인스턴스를 이전 버전 상태로 복원할 수 있습니다.
두 번째 업그레이드 백업은 업그레이드된 데이터베이스 인스턴스에서 새로운 쓰기 작업이 허용되는 즉시 수행되는 업그레이드 후 백업입니다.

백업 목록을 보면 업그레이드 백업이 On-demand 유형으로 나열된 것을 알 수 있습니다. 업그레이드 백업은 이렇게 쉽게 식별할 수 있도록 라벨이 지정되어 있습니다. 예를 들어 MySQL 5.7에서 MySQL 8.0으로 업그레이드하는 경우 업그레이드 전 백업에 Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. 라벨이 지정되고 업그레이드 후 백업에는 Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7. 라벨이 지정됩니다.

다른 주문형 백업에서와 같이 백업을 삭제하거나 인스턴스를 삭제할 때까지 업그레이드 백업이 보존됩니다. PITR을 사용 설정한 경우 보관 기간 동안 업그레이드 백업을 삭제할 수 없습니다. 업그레이드 백업을 삭제해야 할 경우에는 PITR을 사용 중지하거나 업그레이드 백업이 더 이상 보관 기간이 아니게 될 때까지 기다려야 합니다.

주 버전 업그레이드 완료

기본 인스턴스 업그레이드를 완료한 후 다음 단계를 수행해서 업그레이드를 완료합니다.

수락 테스트를 수행합니다.

테스트를 실행하여 업그레이드된 시스템이 예상대로 작동하는지 확인합니다.
(선택사항) 사용자 권한을 업데이트합니다.

MySQL 8.0으로 업그레이드한 경우 MySQL이 보안 및 계정 관리 시스템을 변경했다는 점에 유의하세요. 자세한 내용은 MySQL 8.0의 새로운 기능을 참조하세요.

이로 인해 인스턴스의 MySQL 5.7 버전에서 생성된 사용자에게는 MySQL 8.0에서 직접 생성된 사용자와 동일한 권한이 없을 수 있습니다. 예를 들어 MySQL 5.7에서 업그레이드된 사용자에게는 CREATE ROLE 권한과 DROP ROLE 권한이 없을 수 있습니다. MySQL 5.7에 이러한 권한이 없기 때문입니다. Cloud SQL에서는 사용자 권한과 관련된 문제를 해결하려면 버전을 업그레이드한 후 사용자 권한을 재설정하는 것이 좋습니다.

다음 단계에 따라 사용자 권한을 재설정할 수 있습니다.
1. cloudsqlsuperuser 역할이 부여된 사용자를 만듭니다.
2. 생성된 사용자를 사용하여 다음을 통해 업그레이드된 사용자의 이전 권한을 모두 취소합니다.
```
REVOKE ALL PRIVILEGES ON *.* FROM user@host
```
3. 업그레이드된 사용자에게 예상되는 권한을 부여합니다.
(선택사항) 백업을 만듭니다.

기본 인스턴스를 업그레이드한 후 Cloud SQL에서 자동으로 백업을 생성하지만, Cloud SQL에서 필요한 경우 데이터베이스를 복구할 수 있도록 직접 백업을 만드는 것이 좋습니다.

주 버전 업그레이드 문제 해결

예를 들어 인스턴스에 새 버전에 대한 잘못된 데이터베이스 플래그가 포함된 경우 등 잘못된 업그레이드 명령어를 시도하면 Cloud SQL에서 오류 메시지가 반환됩니다.

업그레이드 요청이 실패하면 업그레이드 요청의 문법을 확인합니다. 요청의 구조가 유효하다면 다음 추천 조치를 살펴보세요.

업그레이드 로그 보기

업그레이드 요청이 올바른 경우에도 문제가 발생하면 Cloud SQL이 projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err에 오류 로그를 게시합니다. 각 로그 항목에는 업그레이드 오류가 발생한 인스턴스를 식별할 수 있도록 인스턴스 식별자와 함께 라벨이 포함되어 있습니다. 이러한 업그레이드 오류를 찾아 해결합니다.

오류 로그를 보려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
인스턴스 개요 페이지의 작업 및 로그 창에서 MySQL 오류 로그 보기 링크를 클릭합니다.

로그 탐색기 페이지가 열립니다.
다음과 같이 로그를 확인합니다.
- 한 프로젝트의 모든 오류 로그를 나열하려면 로그 이름 로그 필터에서 로그 이름을 선택합니다.
쿼리 필터에 대한 자세한 내용은 고급 쿼리를 참조하세요.
- 단일 인스턴스의 업그레이드 오류 로그를 필터링하려면 모든 필드 검색 상자에 다음 쿼리를 입력합니다. 이때 DATABASE_ID를
프로젝트 ID와 인스턴스 이름으로 바꿉니다. 형식은 project_id:instance_name과 같습니다.
```
resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"
```
예를 들어 buylots 프로젝트에서 실행되는 인스턴스 이름 shopping-db로 업그레이드 오류 로그를 필터링하려면 다음 쿼리 필터를 사용합니다.
```
 resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"
```

이전 주 버전으로 복원

업그레이드된 데이터베이스 시스템이 예상한 대로 작동하지 않으면 인스턴스를 이전 버전으로 복원해야 할 수 있습니다. 이렇게 하려면 업그레이드 전 버전을 실행하는 새 인스턴스인 Cloud SQL 복구 인스턴스로 업그레이드 전 백업을 복원합니다.

이전 버전으로 복원하려면 다음 단계를 수행합니다.

업그레이드 전 백업을 식별합니다.

자동 업그레이드 백업을 참조하세요.
복구 인스턴스를 만듭니다.

업그레이드 전 백업이 수행될 때 Cloud SQL에서 실행하던 주 버전을 사용하여 새 Cloud SQL 인스턴스를 만듭니다. 원래 인스턴스에서 사용되는 동일한 플래그 및 인스턴스 설정을 지정합니다.
업그레이드 전 백업을 복원합니다.

업그레이드 전 백업을 복구 인스턴스로 복원합니다. 완료되는 데 몇 분 정도 걸릴 수 있습니다.
읽기 복제본을 추가합니다.

읽기 복제본을 사용하는 경우 이를 개별적으로 추가합니다.
애플리케이션을 연결합니다.

데이터베이스 시스템이 복구되었으면 복구 인스턴스 및 읽기 복제본에 대한 세부정보로 애플리케이션을 업데이트합니다. 데이터베이스의 업그레이드 전 버전에서 트래픽 제공을 재개할 수 있습니다.

제한사항

이 섹션에서는 인플레이스(In-Place) 메이저 버전 업그레이드에 대한 제한사항을 설명합니다.

외부 복제본에서는 인플레이스 주 버전 업그레이드를 수행할 수 없습니다.
MySQL 5.7에서 테이블이 512,000개가 넘는 8.0으로 인스턴스를 업그레이드하는 데 시간이 오래 걸리고 시간이 초과될 수 있습니다.

FAQ

데이터베이스 주 버전을 업그레이드할 때는 다음과 같은 질문을 고려해야 할 수 있습니다.

업그레이드 중에 인스턴스를 사용할 수 없나요?: 예. Cloud SQL이 업그레이드를 수행하는 동안 인스턴스를 사용할 수 없습니다.

업그레이드하는 데 시간이 얼마나 걸리나요?

단일 인스턴스를 업그레이드할 때는 일반적으로 10분 미만이 걸립니다. 인스턴스 구성에서 소량의 vCPU 또는 메모리를 사용하는 경우 업그레이드 시간이 길어질 수 있습니다.

업그레이드 시간은 데이터베이스의 객체 수에 상응하므로 인스턴스에서 데이터베이스 또는 테이블을 너무 많이 호스팅하거나 데이터베이스가 매우 큰 경우 업그레이드에 몇 시간이 걸리거나 타임아웃이 발생할 수도 있습니다. 업그레이드해야 하는 인스턴스가 여러 개인 경우 그에 비례하여 총 업그레이드 시간이 증가합니다.

업그레이드 프로세스에서 각 단계를 모니터링할 수 있나요?: Cloud SQL에서는 업그레이드 작업이 진행 중인지 여부를 모니터링할 수 있지만, 각 업그레이드의 개별 단계는 추적할 수 없습니다.

업그레이드를 시작한 후 취소할 수 있나요?: 아니요. 업그레이드가 시작된 다음에는 이를 취소할 수 없습니다. 업그레이드가 실패하면 Cloud SQL이 인스턴스를 이전 버전으로 자동으로 복구합니다.

업그레이드 도중 내 설정은 어떻게 되나요?

인플레이스 주 버전 업그레이드를 수행하는 경우에는 인스턴스 이름, IP 주소, 명시적으로 구성된 플래그 값, 사용자 데이터와 같은 데이터베이스 설정이 Cloud SQL에서 보존됩니다. 그러나 시스템 변수의 기본값은 변경될 수 있습니다. 예를 들어 MySQL 5.7에서 character_set_server 플래그의 기본값은 utf8입니다. MySQL 8.0으로 업그레이드하면 플래그의 기본값이 utf8mb4로 변경됩니다. utf8로 되돌리려면 플래그 값을 이전 값으로 다시 설정합니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요. 특정 플래그 또는 값이 대상 버전에서 더 이상 지원되지 않는 경우에는 Cloud SQL에서 업그레이드하는 동안 해당 플래그가 자동으로 삭제됩니다.

복제본을 업그레이드한 후 복제가 중단되면 어떻게 해야 하나요?

복제본을 업그레이드한 후 복제가 중단되면 기본 인스턴스의 MySQL 버전으로 롤백됩니다. 복제본을 다시 업그레이드할 수 있지만 문제가 지속되면 복제가 다시 중단될 수 있습니다.

복제본이 롤백되지 않는 경우 두 가지 옵션이 있습니다.

손상된 복제본을 삭제하고 새 복제본을 만든 다음 새 복제본을 업그레이드합니다.

업그레이드에 다시 실패하는 경우 업그레이드 시 기본 인스턴스에 호환되지 않는 변경사항이 추가되었을 수 있습니다. 업그레이드를 통해 문제를 찾고 기본 인스턴스를 수정한 다음 복제본을 업그레이드할 수 있습니다. 자세한 내용은 문제 해결을 참조하세요.
기본 인스턴스 업그레이드

복제본 스레드가 작동하지 않으면 기본 인스턴스의 업그레이드 작업으로 복제본을 다시 만듭니다.

업그레이드된 복제본이 이전 버전으로 롤백된 이유는 무엇인가요?

업그레이드에 실패하면 복제본이 기본 인스턴스의 버전으로 롤백됩니다. 복제본을 다시 업그레이드할 수 있지만 문제가 지속되면 복제본의 mysql.err 로그를 확인하여 소스를 찾을 수 있습니다. [REPL]... failed executing transaction.... end_log_pos...; Failure Reason과 같은 키워드를 검색합니다.

오류 메시지에 사용자 권한 변경과 함께 Access denied for AuthId....가 포함되어 있으면 mysql 및 sys 스키마에서 MySQL 5.7 사용자 권한을 사용하여 실행되는 쿼리가 있을 수 있으며 MySQL 8.0의 보안 및 계정 관리 시스템 변경으로 인해 실패할 수 있습니다. 이 문제를 해결하려면 기본 인스턴스를 새 버전으로 업그레이드하기 전에 기본 인스턴스에서 쿼리를 중지한 후 복제본 업그레이드를 다시 시도해야 합니다. Cloud SQL에서 유사한 문제가 발생할 수 있으므로 새 버전으로 업그레이드하기 전에 기본 인스턴스에서 이러한 모든 쿼리를 일시적으로 중지하는 것이 좋습니다.

MySQL 로그에서 Access denied for AuthID....와 같은 실패 이유가 표시되지 않으면 복제본이 업그레이드된 후 기본 인스턴스에 추가되었을 수 있는 새로운 호환되지 않는 데이터가 원인일 수 있습니다. 다시 업그레이드하기 전에 비호환성 문제를 해결하는 방법은 주 버전 업그레이드 준비를 참조하세요.